Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!ubc-cs!alberta!arcsun.arc.ab.ca!arcsun!kenw
From: kenw@skyler.arc.ab.ca (Ken Wallewein)
Newsgroups: comp.arch
Subject: Re: shell architecture (to glob or not to glob)
Message-ID: <KENW.91Jan20003950@skyler.arc.ab.ca>
Date: 20 Jan 91 06:39:50 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: nobody@arc.ab.ca (Absolutely Nobody)
Organization: Alberta Research Council, Calgary Alberta, Canada
Lines: 56

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

  Well, it might, if it were done that way.  The implementation with which
I am familiar doesn't, and it works rather well.  The syntax of the command
is described in a special "concise command language", which is compiled
into a library, and which the shell keeps in shared memory.

  This has a number of benefits, including _simplified_ software
development (because the syntax of the commands can be decoupled from the
code itself), flexibility (you can call the parser from within your program
if you want to), flexibility (you can change the command syntax without
changing the program -- you don't even need source!), efficiency (you don't
even bother to load the program if the command doesn't follow the required
syntax), and so on.

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

  IF it were done that way.  It needn't be, and such arguments distract
from the value of the central idea.

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

  I agree.  But there are many kinds of power, and many kinds of
simplicity.  Let's keep our minds open.  The idea of having the shell know
something about the syntax expected by programs, as long as it is
configurable, really shouldn't take anything away from you.  The idea is
powerful.  Don't sell it short.

--
/kenw

Ken Wallewein                                                     A L B E R T A
kenw@noah.arc.ab.ca                                             R E S E A R C H
(403)297-2660                                                     C O U N C I L