Xref: utzoo comp.arch:20220 comp.os.misc:1463
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!wuarchive!uunet!aurs01!throop
From: throop@aurs01.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.os.misc
Subject: Re: UNIX mind-set  -> OK, OK!
Message-ID: <59443@aurs01.UUCP>
Date: 15 Jan 91 21:00:53 GMT
References: <1991Jan14.013815.11419@ims.alaska.edu> <11314@lanl.gov> <5340@idunno.Princeton.EDU> <1991Jan14.170115.17178@Think.COM>
Sender: news@aurs01.UUCP
Followup-To: comp.os.misc
Lines: 43

> barmar@think.com (Barry Margolin)
>> pfalstad@phoenix.Princeton.EDU (Paul John Falstad)
>>> jlg@lanl.gov (Jim Giles)
>>> [...] the shells that are bundled with versions of UNIX [...]
>>> trash [...] arguments [.. ie, expand wildcards ..]
>>> [...] This is a choice that _should_ be left to the discretion of the
>>> utility writer.
>> This forces the user to remember, for each individual command, whether
>> or not it processes wildcards.  
> [..But..] There's a
> simple rule: if an argument is a filename, and it makes sense in the syntax
> of the command to refer to multiple files at once, then it is processed for
> wildcards.

Actually, a generalization of this notion is quite attractive.
Suppose, by analogy with C prototypes and coersions, that the commands
the shell knows about have arguments of specific type.  This allows
provision for coersion of things of type string (which the shell
naturally deals in) to things of type (say) filename, or filename list,
or whatnot (which would naturally involve wildcard expansion).

Or, to put it another way, NEITHER the shell NOR the command should be
responsible for wildcard expansion... it ought to be the responsibility
of coersion code associated with a type.  (Given performance constraints
of encapsulating this code in a process, it is likely that the only way
to make this work well is with dynamic linking of some sort.  Also note
that "types" should be coin-able on the fly, just as commands should be.)

Note that such a scheme of "prototypes" and "coersions" supplied
by the notion of shell types can easily solve problems (like a wildcard
intended as the last argument to mv expanding multiply, and thus going
awry, or like expansion-on-the-fly in a GUI or other WIMP-ish interface)
which placing coersions in the shell proper OR in the command proper
cannot address well.

Further, the notion of "flags" can be incorporated as keyword arguments
in such a scheme, leading to a much cleaner and simpler framework
with as much or more expressive power as the current "getopt" notions.

( I am prejudiced in this, of course, since I worked on/with a
  command processor that implemented all these notions and more. )

Wayne Throop       ...!mcnc!aurgate!throop