Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.unix.wizards
Subject: Re: Command interfaces
Message-ID: <432@cresswell.quintus.UUCP>
Date: Fri, 4-Dec-87 06:31:37 EST
Article-I.D.: cresswel.432
Posted: Fri Dec  4 06:31:37 1987
Date-Received: Wed, 9-Dec-87 02:36:12 EST
References: <1257@boulder.Colorado.EDU> <6840002@hpcllmv.HP.COM> <9555@mimsy.UUCP> <798@rocky.STANFORD.EDU>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 73
Summary: MULTICS, PR1MOS, TOPS-20

I mentioned TOPS-10 as a horrible example of a system which did not do
globbing in the shell.  Various people asked whether I had used TOPS-20,
MULTICS, or PR1MOS.

    MULTICS:
	I have never had the pleasure of using MULTICS.
	It has always sounded like a Good Thing, if you can stomach PL/I.

    PR1MOS:
	I've not only used PR1MOS, I have access to some of the manuals.
	The last time I used it seriously was Rev 14, back when they
	were just starting to switch over to UNIX- (or AEGIS-) like
	options.  A release or two before that, you passed options to
	the Fortran compiler by writing octal numbers in the command
	line (this set the P300's A and B registers to the numbers you
	wrote; on PR1ME 400s and 500s the compilers still ran in
	32R = PR1ME 300 mode).  I am **NOT** kidding, folks, you had
	to be able to add octal to use the FTN compiler.
	If SEG understands wildcards this is the first I've heard of it.

    TOPS-20:
	Yes, I have used TOPS-20.  In fact the command line parser
	available under TOPS-10 looked to me like a backwards port
	of the TOPS-20 command line parser.  The snag was that
	ordinary programmers never heard about it (the system calls
	manual didn't mention it because it wasn't a system call,
	and as for a system library manual, forget it, there wasn't
	even an easily accessible routine to parse a file name and
	turn it into the linked bit patterns the system calls wanted).
	The programs I used under TOPS-20 were mostly ones that were
	really TOPS-10 programs that had been ported, so of course
	didn't use the command line parser (good grief, they didn't
	even use exactly the same syntax for file names), so
	IN ORDER TO USE TOPS-20 I HAD TO KNOW WHICH PROGRAMS USED
	THE "STANDARD" COMMAND LINE PARSER AND WHICH DIDN'T,
	and for every program I used that didn't use the standard
	command line parser I had to know its specific peculiar syntax.

There are several problems with having a command line parser of some
sort as a library package.  The fact that a lot of my programs are
rather smaller than a good command line parser like the TOPS-20 one
is one of them.  (Though UNIX System V.3 shared libraries should
make that argument go away;  making shared libraries is an incredible
process but it is Someone Else's Problem.)  The number-one problem is
that when I use a utility I have to remember whether the programmer
was courteous enough to use the standard interface or not, and if he
DIDN'T I am in trouble.  A command line parser which was in a shared
library and which had to be included so that a program could be
invoked as a command would be a good compromise.

There is another argument.  Lisp programmers are familiar with the
EVAL problem.  That is, a function which normally expects to do its
own argument evaluation is sometimes called with its arguments
evaluated.  If program P1 has command line arguments which it calls
wild-card expansion on (say it handles "*") and program P2 wants to
ask P1 to process a particular file whose name it has just computed,
P2 has real trouble if that name looks as though it contains
wild-cards, such as the name "*".  Of course if the wild-card
characters cannot be part of a file-name, some of this problem goes
away.  TOPS-20 avoided this problem by making just such a restriction
and by not being all that good at programs-calling-programs in the
first place.  Another method is to have a "quoting" function which
will quote all meta-characters in a file name.  (How many people
know that setting the 8th bit of characters USED to do this in UNIX?)

Don't forget that programs are users too.
I have used about a dozen operating systems, and of those, only UNIX
and the Burroughs MCP made it anything less than acutely painful for
one program to call another.  I imagine MULTICS must have been good
at it too.  What relevance has this to user interfaces?  Well, the
easier it was for the author of a program to write it, the better the
chance he got it right, and what's the good of any sort of interface
to a broken program?