hedrick@athos.rutgers.edu (Charles Hedrick) (09/07/88)
I've been watching the discussion about shell flavors for some time now, and have come to the conclusion that there's more difference between different implementations in the same family than between the families, at least for interactive use. Lots of people who said "we switched from X to Y and would never think of using X again" were using an outdated version or substandard port of X, whereas the newest version of X had the critical feature that they found in Y. Csh under System V gets a particularly bad deal, since all the System V ports that I've seen are missing all the features that make csh interesting. Bill Joy should sue people for defamation of character when they produce ports of csh that don't support job control. (Yes, it is possible under SVr2 or later.) Ksh and a csh with line editing have essentially the same set of features: - recognition of file names - emacs editing of command lines - job control Each has its advantages, which overall seem to balance out: for ksh or sh with similar features added vi editing as well as emacs job control for any System V that supports sxt's (though you need patches from me to make it usable). the semantics (particularly quoting, but there are some other things as well) are cleaner for writing scripts. for csh with line editing (often called tcsh) you can change key bindings in the emacs line editor (omitting this from ksh was intentional, by the way -- the problem is that for performance reasons on System V you need to keep the size of the data segment down, so Korn didn't want the necessary data structures. We have agreed on a design that will have a satisfactorily small impact, but I haven't had a chance to implement it, and may never...) {} at least in our version, there's a compromise mode that lets you get line editing only when you want it (ESC at the beginning of a line invokes the line editor on the previous line) ksh is getting so many features in it that Unix purists are beginning to retch when they look at the manual
gwyn@smoke.ARPA (Doug Gwyn ) (09/07/88)
In article <Sep.6.17.30.58.1988.24757@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: > at least in our version, there's a compromise mode that lets you > get line editing only when you want it (ESC at the beginning > of a line invokes the line editor on the previous line) > ksh is getting so many features in it that Unix purists are > beginning to retch when they look at the manual One deliberate feature of the BRL Bourne shell is that you don't get any of the added stuff unless you specifically enable it (with an ENV environment variable for the per-interactive shell startup file, "set" options for the other features [capital letters to prevent conflicts with possible standard sh future extensions]). We were also careful not to run the per-shell init stuff for shell scripts, unlike the horrible csh botch in this regard. We also couldn't stomach a lot of the ksh additions and either left them out or found better ways to accomplish them. For example, here is a function I define in my ENV file rather than having to build it into the shell (HISTFILE names the file that gets commands appended to it when the H option is set): history () { ( set +u if [ -z "$HISTFILE" ] then echo "HISTFILE not set" elif [ $# -lt 1 ] then tail -50 "$HISTFILE" else tail -$1 "$HISTFILE" fi ) } By the way, I obtained that as the output of "whatis history", using a feature inspired by Eighth Edition UNIX. "whatis" always produces something that can be fed back to the shell, unlike System V's "type" builtin. I wish the System V developers would pay more attention to the Research folks.