Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ub!dsinc!bagate!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.arch
Subject: Re: Globbing
Message-ID: <19336@cbmvax.commodore.com>
Date: 27 Feb 91 05:58:15 GMT
References: <1991Feb18.152347.28521@dgbt.doc.ca> <474@bria> <19217@cbmvax.commodore.com> <5573:Feb2307:19:4491@kramden.acf.nyu.edu>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Distribution: na
Organization: Commodore, West Chester, PA
Lines: 92

In article <5573:Feb2307:19:4491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <19217@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>> Unless all possible commands fit into the 
>> 	command [flags] arg1..argN globbed_filesystem_arg
>> model, you're pretty much in trouble if you only have shell globbing.

>Why? You didn't provide any justification for this statement.

Because it's obvious.  If I have, for example, two sets of globbed filesystem
arguments, the program can't determine which of the two sets an arbitrary
expanded file name belong to.  If the program does the globbing, dealing
with a command of the form "foo A* B*" is trivial.  Shell globbing won't
allow it.

>> Program driven globbing doesn't force inconsistency, and certainly shell
>> globbing doesn't force consistency, as UNIX is more than happy to prove to
>> anyone using it.

>Why? You didn't provide any justification for this statement.

>Name one thing that you could accomplish by moving globbing into
>programs---that you couldn't accomplish at least as easily by modifying
>the shell. 

Well, with an arbitrary amount of modification, the shell might do practically
anything, including passing the program a totally preparsed set of argument
tags and possibly globbed filesystem space lists as well.  And if the shell
knows the exact syntax of the command, unnatural quoting won't be necessary
either.  However, this changes the shell mechanism completely.  And requiring
separate command description files to go along with the command itself is 
annoying.  At least, it is under VMS, the only system I have used that has
this "feature".

>Here are some disadvantages: 1. Programs (such as shell scripts) often
>invoke other programs, even with (gasp) arguments. 

Sure they do.  Works just great under AmigaDOS, where programs glob.  Never
had a problem, never had a need to turn off globbing, since the program always
knows when it's appropriate.  What's the problem here?

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

Well, perhaps not, though you just told me that I need to extensively rewrite
the user interface and program command line interface so that shell globbing
will solve my problem, rather than resort to an extra for loop and a couple
of function calls in my program.  That's about five minutes work to add to 
any program, by the way, if you're not in a hurry.

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

Of course.  And globbing should be done "the standard way", regardless of
where it takes place.  On a command line, in a "dialog box", on an program's
command line, etc.  My way, the globbing mechanism is the same, the user 
interface is the same, and the programmer's mechanism is the same, no matter
what.  And if you don't like the wildcard set, you can change them in one
place, and every command line, dialog box, grep-style program, etc. gets
the change.  And you don't need to tell the user that a different set of
characters must now be quoted.  How does shell globbing help me in a dialog
box?  Or, for a simpler problem: I have a program for the Amiga called
DiskSalv.  It scans over a damage disk and extracts recoverable file.  If
you don't want them all, you can specify a pattern to search for:

	DiskSalv dh0: ram: FILE #?.c

This would recover every C file from the hard disk DH0: and stick it into the
RAMdisk.  Shell globbing is of no use here, since the filesystem can't even
get at the files in question (though in another program, they may not be
files at all).  Unless the shell knew the program's syntax, the #?.c would
have to be quoted, which is a needless complication, especially for the 
non-expert.  Since the expansion is done within the program, using the same
mechanism as one would normally use in normal file globbing (the function
matches over a standard list rather than a standard filesystem path, but
the syntax is the same in both cases).

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

It's no slower for the program to do it than for the shell to do it.  And
it conserves resources and/or saves frustration, since the program needs only
to handle one expansion at a time, rather than have the shell manage a dynamic
buffer for the occasional command line that expands to 10K or 100K worth of
file names, or worse, run out of space in a fixed sized buffer.

>---Dan


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"What works for me might work for you"	-Jimmy Buffett