Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!caen!ox.com!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.arch
Subject: Re: Globbing
Message-ID: <17704:Feb2719:04:3791@kramden.acf.nyu.edu>
Date: 27 Feb 91 19:04:37 GMT
References: <19217@cbmvax.commodore.com> <5573:Feb2307:19:4491@kramden.acf.nyu.edu> <19336@cbmvax.commodore.com>
Distribution: na
Organization: IR
Lines: 125

In article <19336@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
> 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.

Reality check: You can't convince anyone that globbing causes
``trouble'' just because it doesn't have your pet feature. You have to
explain *why* that feature is useful. I don't think it's trouble that
``the program can't determine which of two sets an arbitrary expanded
file name belong to''; I also don't think it's trouble that globbing
doesn't solve world hunger.

> If the program does the globbing, dealing
> with a command of the form "foo A* B*" is trivial.

It is trivial as is. Why do you want this separation into two sets? What
conceivable function of foo would require A* and B* to be treated
separately? Are A* and B* supposed to be ``corresponding'' sets in some
way? They will usually not have the same size.

Even if you do have some reason for such a foo, you will always survive
with foo [options] -- A* -- B*. -- cuts off all option processing and
will make a perfectly good separator.

Let me guess: You do mean A* and B* to be corresponding sets. In fact,
you're thinking of rename A* B*. Reality check: This is NOT globbing.
You don't want B* to glob; you want the *'s to be replaced by the *'s in
corresponding A's. Right? If I'm right, then you're not talking about
moving globbing from the shell to programs; you're talking about
extending the entire globbing mechanism. This is a worthwhile project,
and I encourage you to write a shell that supports such globbing if you
can figure out a good syntax.

> >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. 
  [ ... ]
> However, this changes the shell mechanism completely.

Yes, changing the shell does mean changing the shell. Surely you agree
that this is easier than modifying every single program.

> And requiring
> separate command description files to go along with the command itself is 
> annoying.

Agreed. The syntax should be stored along with the file. There are also
advantages to storing source code and object code in the same file. But
what does option processing have to do with globbing?

> >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.

Fair enough, but existing UNIX tools have no concept of when they
``should'' glob. If you add globbing then you will break many previously
correct (secure) programs. How do you propose I should invoke ``rm''
upon a file list as root? Do I quote all the arguments? Or does rm
magically ``know'' that it shouldn't glob?

Do you realize how much time it takes to quote arguments? A program
might spend several seconds constructing a million-byte argument list.
It is insanely inefficient to have to quote that list again and again
for each program that sees the arguments.

> >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.

No, I didn't say you had to extensively rewrite the shell. In fact, it
takes just a ``for loop and a couple of function calls'' to handle
rename in the shell. If you want rename to work better, figure out a
better syntax, and then change your shell to handle that syntax. Don't
rewrite programs that shouldn't be involved.

> >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.
  [ various comments on what it means to have consistent globbing ]

Good. I'm glad you understand the advantages of shell globbing. Do you
realize how much work it takes to do the same thing in every program?
Just one mistake and boom, you have a program that doesn't glob. UNIX
isn't meant to load all these requirements on programmers.

> How does shell globbing help me in a dialog
> box?

Your shell handles the dialog boxes. Nah, too easy.

> 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:

I understand what you're saying here. You're not talking about globbing.
You're talking about a pattern-matching problem with superficial
resemblances to globbing.

Globbing replaces a pattern with a list of all filenames matching that
pattern. It doesn't do any more or less than this.

I agree, it is useful to have pattern-matching available for programs
that need it. So?

> >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.

Look, either you have every program looking for arguments to glob, or
you leave globbing in the shell. The first alternative is necessarily
less efficient whenever you pass arguments to more than one program.

---Dan