Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-unix!quintus!sun!decwrl!labrea!rocky!andy
From: andy@rocky.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Command interfaces
Message-ID: <802@rocky.STANFORD.EDU>
Date: Fri, 4-Dec-87 17:44:35 EST
Article-I.D.: rocky.802
Posted: Fri Dec  4 17:44:35 1987
Date-Received: Wed, 9-Dec-87 00:39:20 EST
References: <1257@boulder.Colorado.EDU> <6840002@hpcllmv.HP.COM> <9555@mimsy.UUCP> <798@rocky.STANFORD.EDU> <432@cresswell.quintus.UUCP>
Reply-To: andy@rocky.UUCP (Andy Freeman)
Organization: Stanford University Computer Science Department
Lines: 107

In article <432@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>    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,

The TOPS-20 command parser I referred to is the COMND% system call.
It's in the JSYS manual with every other 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).

TOPS-20 files are manipulated with file numbers (which are assigned on a
per job basis).  GTJFN% (which can parse file names that the user types
and uses COMND%'s filename editing conventions) does this conversion.
(I think that COMND% will call GTJFN% in the appropriate circumstance.)
If you couldn't find this system call, how did you do file I/O?  (Maybe
he's flaming the quality of the library of the implementation of the
language he was using.  The c library on unix machines tends to be far
better, but that doesn't seem relevant to the topic at hand.)

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

Well, c programs that were developed under unix usually don't use
the TOPS-20 command parser after they're ported either.  How could
anyone use such a flawed system....

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

See above.  The COMND% system call requires the system call instruction
and tables that describe the arguments.  These tables contain pointers
to user code that performs the action associated with the argument and
descriptions of the arguments (such as their ascii form for commands).
Unless you're running the ultimate cisc, you can't use less space even
if you do character i/o without buffering and line editing.  (COMND%
is usually in the swappable portion of the OS which is sort of like
a shared library only it has bad connotations.)

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

Yes, TOPS-20 programmers can write their own incompatible command parsers.
Unix doesn't provide much of a choice.

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

TOPS-20 doesn't make programs-calling-programs difficult.  The problem
is that most TOPS-20 programs prompt for their own inputs directly from
the terminal.  This terminal-oriented convention makes it difficult for
one program to use another, but this is not due to anything in TOPS-20.
It is just as easy/hard to write such programs under unix.

I'm not sure what the objection is.  If * is not a legal character in
a file name, it won't appear in a name that has been generated by a
program.  Since TOPS-20's file name<->file number/handle system calls
(GTJFN% and its inverse) know about wildcards and the quoting convention
(as should all programs that generate file names containing "special"
characters in file names), one can pass computed names with wild cards
to other programs.  The called program can decide whether or not to
manipulate all matching files or just the first one (alphabetically).
One can also pass names that use quoted "special" characters - unless
the called program undoes the quoting, they won't be treated specially.
Apart from the fact that wild card expansion is inconvient for user
programs under unix (look at all the programs that don't do it), this
is just like unix.

-andy

ps - TOPS-20 suffers from its lack of a decent library that most programming
languages can use.  On the other hand, the TOPS-20 sites I'm familar with
are more multi-lingual than the unix sites I use regularly.  The latter run
nothing but shell scripts and c and fortran programs.
-- 
Andy Freeman
UUCP:  {arpa gateways, decwrl, sun, hplabs, rutgers}!sushi.stanford.edu!andy
ARPA:  andy@sushi.stanford.edu
(415) 329-1718/723-3088 home/cubicle