From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: The Problem with UNIX
Organization: The University of Texas System - CHPC
Date: Fri, 13 Nov 92 22:32:42 GMT

In article <1992Nov13.180132.141@u.washington.edu> donn@carson.u.washington.edu (Donn Cave) writes:
>evansmp@uhura.aston.ac.uk (Mark Evans) writes:
>
>|michael@chpc.utexas.edu (Michael Lemke) writes:
>...
>|: Well, fixing typos is neat but it is not the essential problem.  My
>|: main complaint about Unix on the user interface level is that there is
>|: no command line interpreter.  What I mean is that after the shell munged
>|: your command line it is *completely* up to the program to interpret the
>|: command line and there is no system function available to parse even
>|: these `standard' options. ...
>
>| Could you say what operating system has this feature.
>| (DOS dos the same, what does VMS do?)
>| Also how the programmer is ment to use it.
>| Does this belong in the operating system (thus resulting in command line
>| options sitting in the PCB, yuck!! add a new 'standard' option rebuild 
>| the system)
>
>VMS does in fact have a command interpreter, DCL.  

When I wrote my little remark up there I actually had VMS in mind.  
Several people pointed out in the meantime that there is getopt (3), of 
which I wasn't aware at the time of writing.  Well, that is a least a 
start but as some people also remarked it is somewhat limited and
overkill in other cases.  Does it allow optional parameters (I know 
getopts in the Bourne shell does not)?

>From a programmer's point
>of view, it's a callable system interface that yields up the parsed command
>line.  From the user's point of view, it's a fairly regular command language
>with consistent rules about abbreviations and optional parameters.
>Unfortunately, it's pretty weak as a programming language, 

True, but we weren't talking about programming although that is a very 
important aspect too.

>but it does have
>"lexical functions" built in to do things like parse file names and wildcards,
>get system information of various kinds and do some text manipulation.

Although definately not as flexible as Unix it is consistent on every level,
i.e., if you parse a filename with f$parse/f$scan from DCL or call 
lib$find_file from a program the behavior is identical.  And concerning 
command line parsing the CLI$ routines are easily callable from any 
language and can even be used for the internal command driven interface 
of your application program.  Their use is a little complex but command 
line parsing is a complex problem -- lex isn't easy to use either (I 
can't).

>
>I'm not strong on VMS internals, but I don't think the command line goes
>into a PCB, but rather is stored in a DCL supervisor area per user - VMS
>may be a little more complex than UNIX in this respect.  There's a command
>history, which presumably is also stored there.  Changing the command set
>does not require rebuilding the system, and users may adopt their own
>command tables or add their own customizations.  Updating the command table
>can be problem, since the change doesn't affect current jobs, but that's
>an implementation issue.
>
>Probably the biggest issue for the programmer is that DCL doesn't expand
>wild cards.  VMS applications expand wild cards using file system services,
>which is much harder programming work but gives you a lot more control over
>the semantics of the operation, as opposed to (int argc, const char **argv).

Well, it is really not that hard to do.  Just call lib$find_file in a
loop until it returns RMS$_NMF.  You'll need the loop anyway.

>For example, one may use the file specification in one parameter to supply
>defaults for the specification in another parameter, further controlling
>whether the defaults are to be applied using output (new) file or input
>(old) file semantics.  That makes "RENAME *.C .C-DIST" a natural idiom in
>VMS, where in UNIX the same operation ("how do I rename a group of files")
>regularly generates questions on this news group.  It does however mean
>that applications accept wild cards only if the programmer invested the
>time.

That is certainly true.  But I am very much convinced that none of the 
typical Unix users understand that the shell is expanding the wildcards
and they will be rather very surprised to see echo * produce a strange 
ls listing.  On the other hand not many people completely understand the
sticky defaults you just described either.

-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: comp.unix.wizards