Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bria!mike
Newsgroups: comp.arch
Subject: Re: Globbing
Message-ID: <481@bria>
Date: 23 Feb 91 18:44:38 GMT
References: <1991Feb18.152347.28521@dgbt.doc.ca> <474@bria> <19217@cbmvax.commodore.com> <5573:Feb2307:19:4491@kramden.acf.nyu.edu>
Reply-To: uunet!bria!mike
Followup-To: comp.unix.misc
Distribution: na
Organization: MGI Group International, Los Angeles, CA
Lines: 69
Keywords:

I'll play the Devil's Advocate for awhile here ...

In an article, kramden.acf.nyu.edu!brnstnd (Dan Bernstein) writes:
>Here are some disadvantages: 1. Programs (such as shell scripts) often
>invoke other programs, even with (gasp) arguments. As is, it suffices to
>use an occasional -- to turn off all argument processing. With globbing
>in every program, this would become much harder.  [...]

Whoa!  The ``--'' encourages getopt() to prematurely return EOF; it does
not, as you have seemingly implied, stiffle globbing by the shell. In any
case, how do you justify your statement that ``turning off'' globbing
would be more difficult from within a program?  Remember, the assumption is
that there is a standard function available that does the argument
processing, and we should further assume that it would accept a notation
to tell it to stop processing the argument list at that point.  Yes, I
am aware of the pitfalls of ``assume'', but this is all hypothetical
anyway. :-)

>2. Many perfectly good applications work without globbing, and we shouldn't
>rewrite them for no obvious benefit. [...]

Programs that don't need argument processing wouldn't call the function.
I'm not quite understanding what it is that you are trying to say here.

>3. Programmers shouldn't be forced to manually handle
>standard conventions just to write a conventional program. Ever heard of
>modularity? [...]

Modularity would not be sacraficed by using a standard function.

4. The system is slow enough as is without every application
>scanning its arguments multiple times and opening up one directory after
>another.

What is the difference between the shell processing the arguments, opening
directories, searching for files, etc. and the program doing the same?
I don't see a performance win here.

Personally speaking ...

I don't like the idea of putting the responsibility for globbing in the
program because it would create an inconsistency.  Right now, I know if
I use the wildcard characters unquoted on the command line, the shell will
attempt to expand them.  This is consistent.  If the program does the
globbing, then we will have to remember which commands glob which arguments.
This could migrate from a minor annoyance to a major headache (rather
quickly, I would think).  To overcome this, some sort of ``standard'' way
of processing the argument vector would have to arise, therefore offering
nothing that the shell does not already provide.  Secondly, I would see
no significant increase in ``ease of use'' or increase in performance.
It would not be a win for the neophyte (because different commands may choose
to process wildcards differently), and there wouldn't be a win for the
veteran (it offers to pointlessly alter something that we already have the
capability to do).

Note also that by quoting the wildcards, your intentions are obvious to
another prerson (ie: the shell is not to expand this when the command
is being evaluated); by removing this ``demarcation'', IMHO, it would make
some scripts more difficult to read and debug because the rules of
globbing would change from command to command, quite possibly without
rhyme nor reason.  (And before you say that it couldn't happen here,
think again ... it most certainly could.)

Cheers,
-- 
Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own.
Title of the week: Systems Engineer    | UUCP: ...!uunet!bria!mike
-------------------------------------------------------------------------------
Remember folks: If you can't flame MS-DOS, then what _can_ you flame?


Brought to you by Super Global Mega Corp .com