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