Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!hao!ames!ucbcad!ucbvax!decvax!decwrl!labrea!rocky!andy From: andy@rocky.STANFORD.EDU (Andy Freeman) Newsgroups: comp.os.misc Subject: Re: What should completion look like on Unix? Message-ID: <882@rocky.STANFORD.EDU> Date: 21 Dec 87 23:46:43 GMT References: <1971@cup.portal.com> <1169@nmtsun.nmt.edu> <588@kuling.UUCP> <871@rocky.STANFORD.EDU> <476@athos.rutgers.edu> Reply-To: andy@rocky.UUCP (Andy Freeman) Organization: Stanford University Computer Science Department Lines: 70 In article <476@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: > I found myself horribly frustrated that I couldn't >use completion for arguments unless the command was built into the >EXEC, [section omitted, I'll comment below] On balance, I >concluded that I prefer tcsh to TOPS-20. (I do agree about wanting >the same parsing features in all programs.) The advantage of the >TOPS-20 style is that when the EXEC knows about the command, it can >handle parsing more intelligently than Unix. The disadvantage is that >when it doesn't, it can't do anything for you at all. Unfortunately >there is no way to tell the EXEC about new commands, short of writing >a parsing routine for the commands in assembly language. In other words, TOPS-20 at its worst is like unix.... A widely used TOPS-20 EXEC (I think it is a dec product) has a programming language, PCL, that can be used to customize and add commands (calling programs as necessary) that can use the completion and recognition features. PCL programs are about as ugly as csh programs. Your proposal for a comparable unix interface package also requires a second data file to tell the interface package how to parse arguments for other programs so this isn't a fatal TOPS-20 flaw. (Unix isn't the only os that allows one to use different command processors. Some non-unix command parsers are programmable. Columbia, or is it NYU, has a substantial pascal library for using COMND and other TOPS-20 features. This sort of thing is sorely lacking from TOPS-20; that's one of the disadvantages of dead os.) Since COMND is in TOPS-20's (swappable) kernel, it could be extended to eliminate the need for this "data" file (assuming that the program being initiated followed certain conventions, ie, it uses COMND, and one wanted to use it as is) when calling programs. Then the interface between called and calling programs would be completely transparent as far as the user is concerned without PCL or separate data files. I'm not convinced that the proposed unix interface library could do this. (Then again, I think that COMND needs to be "fixed" to provide this while people with more experience with it think that it can be done just by convention.) >I am also less than enthusiastic about making all of our command >processors go into cbreak mode so they can understand ?. I think >the tcsh approach of activating immediately on ESC and ^D is quite >reasonable. Is this another unix tty driver "feature"? (I knew it dropped characters, is it also this inflexible?) Under normal use, TOPS-20 manages to keep from even activating comnd, let alone the user program, until one of the wakeup characters is typed, such as ?,,, ^F (used to complete file name fields). One can ask it to wakeup more often. Of course, this isn't just for the os, TOPS-20 user programs can choose what characters cause wakeup; unix usually is more extremist. "?" is the obvious choice for the "show me my alternatives" key, but unix convention already used it for something else.... [from above] > and also that TOPS-20 does completion but doesn't have anything >like the tcsh feature of a key that causes the shell to list every >name starting with what you have typed so far. Standalone "?" in standard TOPS-20 describes the next argument. I thought that the standard "?" processing also did the right thing when one had typed part of an argument - if not, it has been hacked into ours for years. Ours also does this for partial file names. We get programs from other sites, so if the former is a localism, it works transparently. -andy -- 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