Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ulysses.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gsp From: gsp@ulysses.UUCP (Gary Perlman) Newsgroups: net.unix Subject: Re: I, for one, tried ksh and don't like it Message-ID: <866@ulysses.UUCP> Date: Sun, 3-Jun-84 19:16:59 EDT Article-I.D.: ulysses.866 Posted: Sun Jun 3 19:16:59 1984 Date-Received: Tue, 5-Jun-84 19:43:30 EDT References: <161@callan.UUCP> Organization: AT&T Bell Laboratories, Murray Hill Lines: 80 I have to comment on Geoff Kuenning's hate mail on ksh. I have used just about every shell ever run on UNIX, and found his remarks unbeleivable. First, he states he was using a pirated version. Moral and legal issues aside, pirated copies of many things have problems of fidelity. If I see a pirated tape of Star Wars and don't like the visual effects, I may not be sure if the visual effects were poor, or the copying poor. Similarly, if you find the genuine Rolex watch you bought in Times Square doesn't seem to keep good time, and the gold is rubbing off, you get suspicious that something is wrong. This may be what happened with the pirated ksh. Perhaps the version was not properly compiled for the particular configuration. Kuenning's comments are indented, mine are not: ksh is wonderful IF you don't mind waiting up to 60 seconds for your character echoes. I have never had such character echo delays on ksh. Beats me. Ksh is bigger than either than csh or sh, and thus tends to swap out more often (and takes longer to swap). I looked at the binaries on a 4.2 BSD machine for csh and ksh: text data bss dec hex 77824 2048 16740 96612 17964 /bin/ksh 65536 2048 19836 87420 1557c /bin/csh I understand that for programs that tend to stick around, the data space is important for forking. These are the same. On Berkeley machines, where csh usually resides, I think little swapping goes on, but then, I am not really sure. I seem to recall that ksh can be configured to have less built-ins (they are then done with ksh functions) for smaller machines. If you run in "vi" mode, you will quickly find out that it's not a lot more convenient than the csh history mechanism. I find that hard to believe. The csh history has three features I used often: !!, !$, and ^old^new. The general command substitution syntax was always too awkward for me. Ksh substitutes ^[k for !!, $_ (a variable) for !$, and in-line editing for ^old^new. I find the use of familiar editing commands, with pattern matching through the history list, very elegant and natural given that I use vi regularly. The in-line editing is very useful. On human factors grounds, I find ksh gives a lot more feedback of what will be done BEFORE it is done, not AS. If you run in "emacs" mode, it sets your terminal raw and handles character echo itself; this means in practice that on a moderately loaded system echoes can be delayed for quite a while. I haven't seen such annoyingly poor response time since I tried a timesharing system that had been cobbled on top of a batch system, almost 15 years ago. I tries out the emacs mode for the first time after reading this. I did not find it slow. I saw no noticable difference of echo rates compared to the tty handler. Since no mention was made about the load of the system being used, I can only assume everything on his system had poor response rates. Furthermore, ksh is an incredible example of what happens when you try to design a perfectly-compatible upgrade of an existing program (sh) that has run into natural limits. For my money, ksh is a kludge, and a slow one at that! Well, perhaps you are a perfect example of what happens when you cross a British Museum monkey with a fog horn. More to the point, Dave Korn wanted to avoid the mistake of csh that produced different syntax for the same semantics, apparently with little more reason that personal preference. Because people who do write complex shell scripts think sh had a better language than csh, it was natural to extend sh. On our systems, the compatibility is good enough that ksh is used as /bin/sh, with the only noticable difference being execution speed; ksh starts up faster than sh (and hence csh), and it runs faster. That this is done with more functionality is impressive. So whay did Geoff Kuenning of Callan Data Systems think so poorly of ksh? Maybe several common factors are in play: * impatience with learning a new system * preconceptions about how a system will work * attribution of problems to something new I think Mr. Kuenning has jumped the gun here, because if these problems were part of ksh, and not part of the environment ksh was in, I doubt ksh would have the remarkable support it has gained. Gary Perlman BTL MH 5D-105 (201) 582-3624 ulysses!gsp