Ayale-com.668 net.unix-wizards utzoo!decvax!yale-com!mp Fri Jan 8 16:50:36 1982 TOPS-20 like command recognition for unix Here at Yale we have added some modifications to the Berkeley shell, to provide TOPS-20 style command/filename completion. There are some observations of a practical nature, on its acceptance by the user community, that I would like to make: (i) The list of possible commands one could use is usually so large that it becomes an annoyance instead of a help. Here is a list of commands that might start with an `l' (with the typical PATH people use here). (1) yshell ==> l? One of the following : l last lastcomm ld learn leave lex limit lint lisp liszt ln lnall lock login logout look lookbib lorder lpq lpr lprm ls lt lxref lyacc Contrast this with the TOPS-20 @l? Command, one of the following: LATTACH LCOPY LOAD LOGIN LOGOUT or system program name On the TOPS-20, people often type just a question mark to get the list of ALL commands, when they have forgotten the name of a particular command. That, on unix, would produce a listing of more than three screen-fulls. The trouble is, any way of deciding upon an adequate subset is likely to make users limited to that subset, thereby having them miss out on what I consider the best feature of unix (i.e. the abundance of tools) from a user's point of view. This also causes problems when trying to complete a command using , since in a lot of cases one has to type a good part of the command before it is uniquely recognizable. In a lot of other (rather most) cases, there is hardly anything to be completed! (ii) In the modified shell (which we call yshell), there is a provision to provide one's own list of commands to recognize. Turns out, there are a few of people using yshell, who are more familiar with one of our 20's. They use yshell and a suitable list of aliasing (usually set up for them by someone upon asking, "How can I use this system just like the 20?") to produce names and environment resembling TOPS-20. I am not sure this is very desirable. This is just a special case of chosing a supposedly adequate subset of commands. (iii) The regular unix users rarely tend to use the recognition features. Certainly NEVER for completing a command. Even I myself rarely use it, and then only to find out and/or complete file names (e.g. when I have typed /usr/src/cmd but have forgotten the file name in that directory that I want to use). (iv) There is the problem of providing help for possible arguments to a command. Yshell does not attempt to do this, and assumes that an argument has to be a file name. To make it better, one might have to : (a) Modify all the existing programs to use some form of COMND JSYS. or, (b) Provide some system table, where each program's author, (or some maintainer) puts, in some form, the expectations the program has. The first, of course, is unthinkable. The second is very likely to run into high administrative problems, with the way unix systems tend to change and evolve. As a matter of fact, the reason most people use yshell usually is not the command recognition features, but some other features which slowly got added on upon user suggestions. (E.g. history editing with cursor motions, using syntax similar to the local screen editors.) Given the fact that for good or for bad (for bad in my personal opinion), the short unix commands are here to stay, it seems like any 20-style command recognition will be more or less a waste of time. The only people likely to use it are those who are well familiar with the 20 (or similar) style to begin with. For others, while learning the super-un-mnemonic names is a pain, once learnt, typing them out is easy enough, and no one is likely to use much of any command completion. The recognition features on the 20 are good precisely because the command names are long enough to be meaningful to a beginner, but could be annoying to an experienced user, if he/she had to type out all of it. (Or even a unique abbreviation, since in a lot of cases one would not be sure how little is enough for uniqueness. The command completion is helpful there.) Perhaps the manual by the terminal is a necessity. Or a better online documentation scheme. How about a general HELP command which would list the major subsections of programs, and let you interactively walk down the subsections (which might have more subsections), until you find out what you wanted to ? What I mean is something like `learn' but where on picking a certain subsection, you get short descriptions of commands or of further subsections. This could be very helpful when you have just forgotten a command name ( just remember the days when you were starting with unix ) or know the command name, but need a short description of flags, or don't know if anything already exists to do what you want done. ( Something like that has been done at Yale for documenting the local tools on the TOPS-20. ) Does anyone have, or know of, such a help system for unix? -- Mukesh Prasad (decvax!yale-comix!mp) ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.