hardie@sask.UUCP (Peter Hardie) (08/20/83)
TOPS-20 command language (if you can call it a language) is NOT a particularly good one to try to emulate. I dislike it for two major reasons ... 1. It requires very heavy support on the part of the processor to the extent that the so-called 'front-end' processor in the DEC-20 actually passes characters one by one to the backend with no processing of character deletes, line deletes or other editing characters. This means that the backend has to handle each and every character transmitted by the user as it is sent. The front-end therefore becomes$!very expensive piece of wire. The reason for this idiocy is that since only the backend knows the actual command names and filenames (which can also be expanded with <ESC>) then the backend has to see all the characters that you type. Admittedly, DEC implemented the front-end in about the worst possible way but it is still a crummy idea. 2. It allows users to play around with commands that they don't understand. Every year we have students here who play with the ? and escape keys e.g. t? [tops fills in with all commands known by exec beginning with T ] talk ? [tops now tells them that the next arg is an octal line number] talk 53 [now they are interfering with a user on line 53 because even if the user has refused messages his terminal will still beep for a while] and of course if nothing interesting happens then they try talking to as many lines as they have time for until they find a user who has not refused links. For those of you lucky enough never to have used a dec-20 the talk command is similar to 'write' and refusing links is essentially the same as 'mesg n' . They can also play around with the advise command and a huge number of others. The real problem is that they can discover the names of commands and their syntax without having to read a manual (they usually don't discover the help command until two days before end of term :-) and thereby discover what the command actually does. My opinion is that both menus and commands have their place but neither one is really useful without a well-trained end-user.
mcg@shark.UUCP (Steven McGeady) (08/22/83)
I think that the major reason why tops-20 style command completion will never work on UNIX, or more modern operating systems is that UNIX is a much "richer" environment than tops-20. That is to say, on tops-20 there may be as many as 50 commands. On a typical UNIX system there are well over 200 (on our system there are 548). It is not that UNIX is bloated, its just that you can do *more things*. BTW, on our system, the t<esc> example would return this: t tab tinker today tar tee test time tp true t300 t300s t4025 t450 tabs tail tbl tc tek tk touch tp300 tr troff tsort tty talk td tekroff temacs tf tpcopy troll trouble tsh tekecs telnet tra trman trpt tset (42 commands) and it is not the most popular initial letter. My point is: command completion may have worked fin on tops-20, but don't try to apply it to UNIX, or any reasonably rich operating environment. S. McGeady Tektronix, Inc.
mark@cbosgd.UUCP (08/22/83)
I think command completion would work fine on UNIX, if it could be implemented efficiently (e.g. the tty driver would have to be modified to wakeup on several characters). I've used versions of csh with command completion (certainly at least file name completion worked well) and liked them. TOPS 20 may have only 50 builtin shell commands (compared to about 10 in UNIX) but there are lots of user programs out there too. There would certainly be problems with the notion of a PATH. The implementations I've seen just look in the current directory. However, once a decision is made, this wouldn't be much of a problem. By the way, don't blame DEC for escape recognition. BBN designed this for TENEX over 10 years ago. DEC just copied it into TOPS 20, which is just a TENEX clone. Kind of like USG copied vi from Berkeley. (I don't know if DEC rewrote the code or got it from BBN - USG certainly got the vi code from Berkeley rather than rewrite it from scratch.)
dyer@wivax.UUCP (08/23/83)
As far back as 1974, Bruce Borden's "Harvard Shell" implemented command completion for a subset of commonly-used commands. Initially it ran in RAW mode, with automatic completion after the 1st two letters of the command were typed. Subsequent arguments could be prompted for by hitting the ESC key. Later, the V6 shell and the Harvard Shell were merged, and ESC optionally expanded commands known to the shell; otherwise, it acted like the vanilla V6 shell. Naturally, a special TTY driver was needed to support this efficiently. This feature was taken straight from BBN TENEX, though it lacked much of TENEX's "hit-an-ESC-anywhere" generality. At that time, it was thought that the UNIX shell was too arcane for Harvard students. The Harvard Shell is still in use on their 2.8BSD and 4.1BSD systems, primarily by naive users. Most graduate quickly to the C shell.
joe@fluke.UUCP (Joe Kelsey) (08/23/83)
It has always been my opinion that the "best" system to work on would be one that included the command completion and recognition capabilities of TWENEX (TENEX/TOPS-20), the hirearchical HELP facility from VMS in a UNIX environment. Mark mentioned that he didn't know how the notion of PATH would fit into a command completion environment - well it works just fine in TOPS-20! TOPS-20 logical names are much more flexible than those of VMS in that a logical name can include multiple directories - in effect a PATH specification. This works just fine if you define the logical name SYS: to be whatever your favorite PATH is. Command completion works such that if a builtin command does not match your typein, then the EXEC searches the SYS: path (first using your local definition, then using the system definition), for an executable file whose name either matches your typein or can be completed to match your typein, depending on context. Thus, TOPS-20 has always had the UNIX feature of being able to "create" new commands by simply naming the executable file, and including the directory where the file resides in your definition of SYS: (or by including DSK: (e.g. ".") in the path). I have also found that TOPS-20 was one of the more pleasant systems to administer. From a systems programming standpoint, I would rank TOPS-20 ahead of UNIX, simply because DEC is good at producing reams of documentation, which is still sorely lacking for UNIX. Command completion in TOPS-20 is not limited to just the EXEC (shell), but is available to any and all user programs who want to take advantage of the COMND jsys (system call). It would not be in the UNIX spirit to add a system call to do this, but you could certainly design a facility for compiling this kind of interface into programs (some combination of lex and yacc with probably a few mods to the kernel) to provide a more consistent user interface. People haven't mentioned one of the more recent innovations in TOPS-20, PCL (Programmable Command Language) from CMU. PCL provides a naive user access to all of the command completion facilities and an easy way to extend the EXEC in a consistent manner. PCL is an ALGOL-like language with integers and strings which is compiled by the EXEC to produce new commands. I would really like to see some sort of facility like this available on UNIX, if only for the fact that it would really encourage people to use a consistent user interface - something that UNIX sorely lacks! Well enough rambling for now. I'm no longer associated with a TOPS-20 system, and with the demise of Project Jupiter, it looks like DEC is giving up on TOPS-20 as well. Sigh. I can live with VMS and UNIX, but my heart belongs to the -20. /Joe