Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!shelby!neon!news
From: andy@Theory.Stanford.EDU (Andy Freeman)
Newsgroups: comp.arch
Subject: Re: shell architecture (to glob or not to glob)
Message-ID: <1991Jan21.200544.29795@Neon.Stanford.EDU>
Date: 21 Jan 91 20:05:44 GMT
References: <1991Jan14.013815.11419@ims.alaska.edu> <11314@lanl.gov> <5340@idunno.Princeton.EDU> <1991Jan14.170115.17178@Think.COM> <360@bria> <1991Jan17.185527.9824@Neon.Stanford.EDU> <365@bria>
Sender: news@Neon.Stanford.EDU (USENET News System)
Organization: Computer Science Department, Stanford University
Lines: 57

In article <365@bria> mike@bria.UUCP (Michael Stefanik) writes:
>In article <1991Jan17.185527.9824@Neon.Stanford.EDU> Theory.Stanford.EDU!andy (Andy Freeman) writes:
>>In article <360@bria> mike@bria.UUCP (Michael Stefanik) writes:
>>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.
>
>This puts an unecessary burden on the shell and would degrade startup time
>on the image.  The shell would have to open the program file, seek to this
>mythical table, parse it, close the program, and then hand it to the OS, which
>would open the file again, etc.  This is *far* too much overhead for the
>minimal benefits that it would provide.

The most expensive resource on my system is the users, and that's true
of every site with less expensive computers than Los Alamos and
Livermore.  In any event, strings(1) is pretty fast and the argument
description can be preloaded.  (My shell has a program/command hash
table already, so it isn't unreasonable to preload.)

>>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.
>
>I may be nitpicking, but I don't believe that the shell thinks that *all*
>arguments are filenames ... only those arguments that include special,
>well-known characters that are not quoted.  The shell doesn't actually
>give a dang what you are specifying as aguments.  Again, the shell follows
>a predefined set of rules.

The point is that the shell CAN'T do anything useful with arguments
that aren't filenames.  If one of the arguments to a program is
uniquely specified by the prefix "a", the shell can do something
useful if the argument happens to be a filename.  However, if it
isn't, either the user gets to type more or the program has to do its
own expansion.  In any event, the shell can't help a user know what
kind of arguments are expected or what will be done with them.

There's no question that the shell is "complete", the question is
whether or not it is a useful command processor.  I note that menu
systems are becoming more popular.  I doubt that this is because
people like moving their hands from the keyboard to a mouse and back,
but because the argument parsing and instantaneous help provided is
markedly superior to the best bare unix can provide.

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