Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!shelby!neon!news
From: andy@Theory.Stanford.EDU (Andy Freeman)
Newsgroups: comp.arch
Subject: Re: UNIX mind-set  -> OK, OK!
Message-ID: <1991Jan17.185527.9824@Neon.Stanford.EDU>
Date: 17 Jan 91 18:55:27 GMT
References: <1991Jan14.013815.11419@ims.alaska.edu> <11314@lanl.gov> <5340@idunno.Princeton.EDU> <1991Jan14.170115.17178@Think.COM> <360@bria>
Sender: news@Neon.Stanford.EDU (USENET News System)
Organization: Computer Science Department, Stanford University
Lines: 40

In article <360@bria> mike@bria.UUCP (Michael Stefanik) writes:
>   with it, and compile.  Under what you are proposing, I would additionally
>   have to tell the shell that the program has been changed.  This is a
>   real hassle.

So is updating documentation, but it is worthwhile.

Besides, there's no particular reason that one can't include a
description of the argv arguments to the executable.  Then, the shell
can merely look at the program it is about to invoke to decide what it
(the shell) should do with the typed arguments before invoking the
program.

>2. In my view, it is the job of the shell to parse (and glob) args, not the
>   programs that are being given the arguments.

I'd love to have a shell that did something reasonable with arguments.
Instead, all I can have is a shell that assumes that all arguments
are filenames and expands them as filenames.

The issue isn't whether or not I can pass "*" as an argument to a
program, it is what to do about arguments that aren't filenames.
Shells treat each and every argument as a file name.  If an argument
isn't a filename, there's no way to have the shell expand it
appropriately.

BTW - There are things one would like to see a command processor do
beyond expand arguments.  For example, it could tell you what kind of
argument is expected, possibly including a list of options.  It might
even tell you what it is going to do with that argument.  (For
example, the command parser could tell you that mv's first argument is
a source, if you then asked what the second argument was, it could say
"destination or another source, in which case the last argument must
be a directory".)

-andy
--
UUCP:    {arpa gateways, sun, decwrl, uunet, rutgers}!neon.stanford.edu!andy
ARPA:    andy@neon.stanford.edu
BELLNET: (415) 723-3088