Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!uupsi!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.arch
Subject: Re: Globbing
Message-ID: <5573:Feb2307:19:4491@kramden.acf.nyu.edu>
Date: 23 Feb 91 07:19:44 GMT
References: <1991Feb18.152347.28521@dgbt.doc.ca> <474@bria> <19217@cbmvax.commodore.com>
Distribution: na
Organization: IR
Lines: 30

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.

> 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. After all, you're complaining about the user interface, and
the shell is the program responsible for that interface.

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. 2. Many perfectly good
applications work without globbing, and we shouldn't rewrite them for no
obvious benefit. 3. Programmers shouldn't be forced to manually handle
standard conventions just to write a conventional program. Ever heard of
modularity? 4. The system is slow enough as is without every application
scanning its arguments multiple times and opening up one directory after
another.

---Dan


Brought to you by Super Global Mega Corp .com