Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bria!mike
Newsgroups: comp.arch
Subject: Re: shell architecture (to glob or not to glob)
Message-ID: <365@bria>
Date: 19 Jan 91 20:21:51 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>
Reply-To: mike@bria.UUCP (Michael Stefanik)
Organization: Briareus Corporation, Los Angeles, CA
Lines: 98

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

The documentation I write at the *end* of the development phase; maintaining
command databases while I'm still developing is what I think is the pain.

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

Going the opposite way, and having exec() deal with command arguments insofar
as qualifying them, etc. is a *worse* kludge and would force the COFF to
be revised.

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

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.  If you don't like those rules, then write your
own shell.  IMHO, this is the way it should be.  If you don't like something,
then you're free to do it yourself another way.  As a programmer, though,
the "standard" UNIX shells suit me just fine, thank you.

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

This is decidedly what I *WOULD NOT* like to see in UNIX.  I don't want
the operating system, the shell, or your program second-guessing me.  If
I did something wrong, then a simple, short, straightforward error message
is all I want (along with a error status returned by the program).  I
find myself doing this so often in my scripts ...

	somecommand >/dev/null 2>&1

I know this is going to irk a few people, but I think that UNIX is *too*
verbose as it is (AIX is ridiculous with it's multiline error messages).
The error messages (as is) are too complex for the ignorant user, and contain
too much meaningless fluff for the programmer.

The day I stop using using UNIX is whan I see messages like this:

cp: (meaning "copy"): I'm sorry, but I could not create your file
    /tmp/foo because there is not enough free blocks on that filesystem.
    Please do a "df -v /dev/hd3" to determine the free space and remove
    any extraneous files.

Or how about something as nauseating as this:

mv: (meaning "move"): You didn't supply a second argument, please enter one.
    File:

The one thing I *love* about UNIX is that it is terse, doesn't second guess,
and assumes that you know what you're doing (thereby giving me all the
freedom that I want).

The real challenge is to provide an end-user interface that is simple to
use, and covers most of the bases.  However, a fundamental deviation from 
the philosphy of "power to the programmer" would be a major mistake, in my
mind anyhow.
-- 
Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
UUCP: ...!uunet!bria!mike
--
technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly
found to be saying things like "Well, it works on my DOS machine ..."