Xref: utzoo comp.os.misc:1619 comp.arch:21231
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.os.misc,comp.arch
Subject: Re: shell architecture (to glob or not to glob)
Message-ID: <19503@cbmvax.commodore.com>
Date: 5 Mar 91 00:30:45 GMT
References: <378@bria> <KENW.91Feb25170431@skyler.arc.ab.ca> <5615@awdprime.UUCP> <KENW.91Feb26134115@skyler.arc.ab.ca> <1991Mar3.020451.5596@metapro.DIALix.oz.au>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Followup-To: comp.os.misc
Organization: Commodore, West Chester, PA
Lines: 54

In article <1991Mar3.020451.5596@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:
>There is a convention that a "--" terminates command options. This is
>how you can do an "rm -- -ha.ha" without rm complaining.
...
>Again, read the convention explained above. This convention is
>explained in INTRO(1) of most UNIX manuals.

	Unfortunately, the user must know in advance if a glob will result in
-xxx filenames BEFORE invoking the command, or must always use -- on all
command lines.  What would happen someone created a file named -r in a 
directory where you often delete some files with *, or *.c, or whatever?
Or -rf?  There are all sorts of other nasty possibilities that you can't know
about unless you do the globbing once to see which files it matches.

	BTW, according to the man page I get for rm, it doesn't follow
your standard: it wants rm - -ha.ha.

>Not that mv does this now, but globbing would pass the unaltered
>pattern to the program as an argument, if there are no matches. i.e.
>if there are no compress* files, then mv could be clever about it,
>because it would be passed the pattern compress* as an argument.

	What if there was a match?  The point is that it's an output spec,
not an input one, and therefor shouldn't be matched against existing files.
You could design an interface where the shell globbed, but preserved the
original argument so the program could pick.  That means you may spend a lot
of cycles/disk-accesses to glob arguments that don't need it.

>As I mentioned before, all the shells I know of, allow you to turn off
>globbing.

	An implicit admission that shell globbing can get in the way at times.
It's painful to turn it off just because you want to run a specific command.
Also, we're talking more about which design is better (on their own merits),
not whether you can at this date retrofit Unix to have this be the
default.  That's why we're not discussing this in comp.unix.shells.
(BTW, I'm sending followups to comp.os.misc).

	You can get around most any annoyance with enough work, quoting, etc.
However, which is better for the user?  This is why I reject the arguments
that making calls to a system globbing function is too much work for 
programmers: yes, it is (a very little) more work.  However, I think it
produces a far better and easier to use interface for the user of the
system.  It also makes it easier to have a richer globbing language (more than
merely * and ?, you can have more RE's - but if you do shell-globbing, you'll
end up with command lines that look a bit like Lisp code because of all the
quoting and escaping).

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)