hedrick@athos.rutgers.edu (Charles Hedrick) (12/21/87)
>No you don't have exactly the same behavior. You have recognition for >command names and arguments that are file names. TOPS-20 command parser >provides recognition for arguments that aren't file names as well as >those that are. You can also ask it what arguments are legal. There's a tradeoff here. I recently went back to our DEC-20 system to do a few things. I found myself horribly frustrated that I couldn't use completion for arguments unless the command was built into the EXEC, 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. 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. I have a comment about the current tendency to write TOPS-20 command emulation for Unix. To me the most important thing about TOPS-20 is that it provides its fancy parsing features consistently in both the EXEC and programs. The equivalent on Unix is to provide intelligent Unix-oriented command processing consistently in the shell and all programs. Having a few applications that simulate TOPS-20 is *not* an improvement, unless there is general agreement to move to that style. I'd much rather see a Unix command processing convention adopted that is a bit more consistent with existing Unix. I suggest the following: 1) provide a subroutine for parsing file names that is consistent with (probably stolen from) tcsh/4.3csh. It would understand ~, and do completion and listing (i.e. ESC and ^D from tcsh). This would be used by all new programs that want to get file names from a user, and would be retrofitted into old programs as maintenance is done to them. (The mail readers should probably be the highest priority.) Lock the people responsible for tcsh and Gnu emacs in a closet and don't let them out until they agree on a single character to use for file name completion (tcsh uses ESC, Emacs uses TAB). 2) provide a subroutine for parsing command keywords. Although the shell currently does not allow abbreviations, most recent Berkeley programs (lpc, mail, ...) seem to be following the TOPS-20/VMS convention of having longish command names and accepting any unique abbreviation. Again, all new programs and over time old programs should all use this style. The shell should switch to it for interpreting the command name. Long aliases should be provided for the more cryptic existing commands (copy, rename, delete, type, append, and print as aliases for cp, mv, rm, more, cat, and lpr). (This could be done in many cases simply by creating hard links.) 3) consider modifying tcsh/4.3csh to read a file like /etc/tcsh-templates to define commands for which more intelligent argument processing would be done. Write the code for doing this so that it could be used by other programs as well. One would want the ability to describe the commonly-used types of arguments and options. Once this is done, we should start encouraging long option names, which would presumably be processed as on TOPS-20/VMS. But please, start them with -, not /. Let's not simulate TOPS-20. 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.
karl@tut.cis.ohio-state.edu (Karl Kleinpaste) (12/21/87)
hedrick@athos.rutgers.edu writes:
Lock the
people responsible for tcsh and Gnu emacs in a closet and don't let
them out until they agree on a single character to use for file name
completion (tcsh uses ESC, Emacs uses TAB).
You needn't be so hard-hearted about that. Paul put a number of the
features of my line-editing csh into his tcsh, but his editor still
doesn't allow the arbitrary binding of keys to command functions. If
you allow such a feature, then you provide one default and allow Joe
Random to do what he will. I have a file ~karl/.bind which specifies
that both ^[ and ^I do a "recognize" function, which is what the
completion function does. Piece o'cake, took maybe 10 minutes to
write that particular hunk of code 2 years ago.
(My line editor [land-locked tho' it may be] does both vi- and
emacs-style editing based on a dispatch table of ASCII chars. T'ain't
tough to write code that diddles the function pointers in that table
based on a new "bind" command...)
--
Karlchet@mandrill.CWRU.Edu (Chet Ramey) (12/21/87)
In article <476@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >1) provide a subroutine for parsing file names that is consistent with >(probably stolen from) tcsh/4.3csh. It would understand ~, and do >completion and listing (i.e. ESC and ^D from tcsh). >Lock the >people responsible for tcsh and Gnu emacs in a closet and don't let >them out until they agree on a single character to use for file name >completion (tcsh uses ESC, Emacs uses TAB). I don't know whether it's "standard" tcsh (I didn't set it up here), but the version we have running on mandrill (VAX-11/780, 4.3 BSD) uses TAB for filename completion. The man page is consistent with this usage. Is this the norm? Chet Ramey chet@mandrill.CWRU.Edu {cbosgd,decvax,sun}!mandrill!chet I think that all right-thinking people in this country are sick and tired of being told that ordinary decent people are fed up in this country with being sick and tired. I'm certainly not. But I'm sick and tired of being told that I am. Monty Python
andy@rocky.STANFORD.EDU (Andy Freeman) (12/22/87)
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 ?,<cr>,<esc>, ^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
esj@beach.cis.ufl.edu (Eric S. Johnson) (12/23/87)
In article <2335@mandrill.CWRU.Edu> chet@mandrill.CWRU.Edu (Chet Ramey) writes: > >I don't know whether it's "standard" tcsh (I didn't set it up here), but >the version we have running on mandrill (VAX-11/780, 4.3 BSD) uses TAB >for filename completion. The man page is consistent with this usage. Is >this the norm? > >Chet Ramey chet@mandrill.CWRU.Edu {cbosgd,decvax,sun}!mandrill!chet > Well, one thing I love about tcsh(and emacs for that matter) is that you can rebind filename completion (and just about every other "special" key) to be what you want. I dont even remember what the default filename completion key is, and I did set up tcsh here. Consistancy is easy. -- In Real Life: UUCP: ...ihnp4!codas!ufcsv!beach.cis.ufl.edu!esj Eric S. Johnson II Internet: esj@beach.cis.ufl.edu University of Florida "Your species is always dying and suffering" -Q
ignatz@chinet.UUCP (Dave Ihnat) (12/27/87)
In article <882@rocky.STANFORD.EDU> andy@rocky.STANFORD.EDU (Charles Hedrick) writes: > [included text] [1] > In other words, TOPS-20 at its worst is like unix.... > > [some reasonable information and comments] [2] > Is this another unix tty driver "feature"? (I knew it dropped > characters, is it also this inflexible?) ... > [more reasonable TOPS-20 information and observations] >-andy Please...I'm neither going to defend Unix, nor attack TOPS-20, or vice versa. But I've sat through 8 years of OS/Editor/Language-Wars on the Net, and this is just the tinder that will start said again. [1] above is sheer opinion, and can lead to a barrage of articles, if not commented as a humorous comment. [2] is either a conscious or unconscious over-simplification, as well as an opinionated (and, if the 'inflexible' comment is serious, uninformed) statement; again, this will simply add fuel to a useless 'my OS really *can* do this! Better than yours!!' message flood on the net. Sorry if I'm cranky...but I've the-day-after-Christmas blahs, and really want to nip this thing in the bud. The information in the above article on TOPS-20 is useful and welcome; thank you. -- Dave Ihnat ihnp4!homebru!ignatz || ihnp4!chinet!ignatz (w) (312) 882-4673
andy@rocky.STANFORD.EDU (Andy Freeman) (01/05/88)
In article <2028@chinet.UUCP> ignatz@chinet.UUCP (Dave Ihnat) writes: >In article <882@rocky.STANFORD.EDU> andy@rocky.STANFORD.EDU (Andy Freeman) >writes: [I was responding to Charles Hedrick's comment that when invoking a program, instead of a command (builtin to csh/sh fans), the default TOPS-20 exec doesn't offer any help.] >> In other words, TOPS-20 at its worst is like unix.... Dave Ihnat objects to this comment as being sheer opinion and thinks it should have been labeled as humorous. I was being overly snide, my apologies, but the comment is factual. Ignoring tcsh (and 4.3bsd csh with filec set), the command parsers in unix shells DON'T have any help facilities for either commands or programs; they only have line editing commands. That's all that the TOPS-20 exec (shell to unix fans) does for invoked program arguments. (Remember, the exec knows more about commands, so the command line parser has recognition/ help for arguments whether they are file names or other kinds of arguments.) tcsh (and 4.3bsd csh with filec set) recognizes command and program names (as does TOPS-20) and has recognition for file names as arguments. It does this no matter what type of arguments the command/program is expecting; most unix arguments are file names so this isn't wrong too often. Adding tcsh capability to the TOPS-20 exec (shell to unix fans) would take about 30 minutes but it hasn't been a big priority here. (We just figured it out so that I could quote the time to implement.) Why? Well, it only affects how the exec parses command line arguments for programs and since the exec doesn't know what their arguments look like (they may not be file names), it would recognize a file name even though the program wants something else. Tcsh does this and it isn't fatal (just don't type <esc>), but other TOPS-20 recognition is always type-correct and this would be an anomaly. The second factor is that TOPS-20 programs parse their own arguments because they can do correct recognition (they know what they want); command line arguments are merely shorthand and some programs don't even bother to accept them. >> Is this another unix tty driver "feature"? (I knew it dropped >> characters, is it also this inflexible?) ... Hedrick had just said that adding a help character would be inefficient under unix' tty driver. That sounds inflexible to me. I've been "trained" to avoid the things that convinces the 4.nBSD terminal drivers to drop characters. Other unix' may be better. TOPS-20 is dead and unix isn't, but that doesn't mean that unix does everything better. I've used both for several years and they have different strengths. -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