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?