Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!think!ames!sri-spam!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.unix.wizards
Subject: Re: Command interfaces
Message-ID: <346@athos.rutgers.edu>
Date: Fri, 4-Dec-87 14:41:46 EST
Article-I.D.: athos.346
Posted: Fri Dec  4 14:41:46 1987
Date-Received: Wed, 9-Dec-87 06:46:01 EST
References: <1257@boulder.Colorado.EDU> <6840002@hpcllmv.HP.COM> <9555@mimsy.UUCP> <798@rocky.STANFORD.EDU> <432@cresswell.quintus.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 66
To: ok@quintus.UUCP


Richard O'Keefe says basically that it's better to let the shell parse
file names rather than individual programs because there are both
technical and people problems with getting people to use a consistent
command parser in their programs.  This response seems very odd to me.
At most the existing Unix shell does wildcard file name parsing, and
then only for commands typed directly to the shell.  That's only part
of the problem.  Programs still have to parse options and arguments
that aren't file names.  And many programs have internal commands once
you start them.  Because Unix depends upon the shell for parsing,
there is no standard parsing library for use in programs.  Thus ~
works in file names on the command line, and in Emacs, but not when I
use the ~r command in mail to read a file.  And of course every
program has its own oddities in parsing options.  As for programs that
themselves have command scanners, it seems to depend upon what
operating system that author had used before they came to Unix.  Some
of the newer Berkeley command scanners (e.g.  lpc) look a lot like a
typical VMS or TOPS-20 scanner.  Others (mail) tend to the
single-letter command tradition of ed.  In the long run, I think we'd
all be better off to have an "official" command parser that was used
in parsing both the command line and commands given inside the
program.  I think TOPS-20 proves this point very clearly.  TOPS-20 is
a second-generation offshoot of TOPS-10.  TOPS-10 was a lot like Unix.
The command scanner (or a program called from it, COMPIL) would take
some central responsibility for what was typed on the command line.
But once you went into the program, you got whatever the author
happened to come up with.  Like Unix, there was an old tradition of
single-letter commands and options,

  outfil=infile/o/23d

and a new one of longer names:

  outfil=infile/option/detail:23

This variation all stopped with TOPS-20, with its single official
command scanner.  It took a number of years before there were
native-mode TOPS-20 programs for everything, so for a while we had all
the TOPS-10 command styles, plus the new TOPS-20 one.  But for the
last 5 years or so, the normal TOPS-20 user at Rutgers has been using
only native TOPS-20 programs.  And the native TOPS-20 programs all use
the TOPS-20 scanner.  Because TOPS-20 programs were all done in
assembly, the scanner was put into the kernel, and there were system
calls to use it.  (TOPS-20 tended to use the kernel as a shared
library.  This sounds sort of wierd, but it works remarkably well.
They were able to keep system call overhead low enough that programs
actually used system calls to do things like parse a floating point
number, convert date formats, etc.  On the 20, assembly language
programming was remarkably pleasant.)  Obviously on Unix this would be
done via a library.  I think the TOPS-20 experience is important,
because much of it would be duplicated if we tried to fix Unix
parsing.  As with TOPS-20, there would be a period where the old and
the new overlapped.  But a properly designed new standard would be
enough of an improvement that I think we could be fairly sure it would
take over within a few years.  People do use standard routines when
they are available.  

As Mark Crispin has said, if we are lucky, within a few years, Unix
will have all the amenities that TOPS-20 users had 10 years ago.  Then
we can all start moving forward again. (But this time no hardware
vendor will be able to pull the rug out from under us.)  [To be fair,
much the same process of standardization also took place on TOPS-10,
which continued in parallel wth TOPS-20.  TOPS-10 gots its own
official scanner, this time as a library, called SCAN/WILD.  I haven't
been around TOPS-10 recently enough to know whether SCAN and WILD have
managed to get rid of all the old ad hoc command scanners.  Certainly
it was moving that way last time I looked.]