geoff@callan.UUCP (06/01/84)
All this "ksh is the greatest thing since sliced beer" stuff prompts me to stick in a contrary opinion. I have had an opportunity to try out ksh. (An illegally-made outside-Bell copy, I might add, but I wasn't the one who took it, ported it, or installed it, and it's not on MY machine that I tried it, so please no anti-piracy flames. I do not support the theft, even though I did take advantage of it long enough to try ksh across a modem.) Anyway, ksh is wonderful IF you don't mind waiting up to 60 seconds for your character echoes. Ksh is bigger than either than csh or sh, and thus tends to swap out more often (and takes longer to swap). If you run in "vi" mode, you will quickly find out that it's not a lot more convenient than the csh history mechanism. 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. 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! Geoff Kuenning Callan Data Systems ...!ihnp4!wlbr!callan!geoff
gsp@ulysses.UUCP (Gary Perlman) (06/04/84)
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
guy@rlgvax.UUCP (Guy Harris) (06/04/84)
Well, as someone who hasn't tried "ksh" because it hasn't been made available outside AT&T, but who wishes he could: > 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. > 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. Your diagnosis is probably correct. The reasons character echoing by the TTY driver is faster than character echoing by a program are: 1) Doing it in the program requires more CPU cycles - more layers of software to pass through, more system calls (which are not cheap), and usually more processing per character (because if the processing the TTY driver were sufficient, the program would probably run in cooked mode and let the TTY driver do the work). So if the system is heavily CPU-loaded, a program which does character echoing will give slow response. 2) The kernel, including the TTY driver, is never swapped out. A user program doing echoing can be swapped out; if the system is heavily memory-loaded (i.e., the programs running require more active memory than the machine has), a program which does character echoing will give slow response. On such a loaded system, "ksh"'s "emacs" mode won't be the only thing that suffers; every screen editor will probably suffer too. "vi" is a hefty chunk bigger than "csh" or "ksh", so it may suffer even worse on a memory-loaded system (although, on a paging system, it might not if its working set isn't bigger than "csh"s). > 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. For forking and for swapping, the data space counts more than the text space. The text space isn't copied on a "fork" (on a Berkeley system, the data space isn't copied on a "vfork", though, so depending on where "csh" and "ksh" do "vforks" instead of "forks", this may not make a difference). Furthermore, texts are not swapped out on a System III or V7 system until the last process using the text is swapped out (I'm not sure what System V or Berkeley systems do), so they're less likely to be swapped out - and they aren't really "swapped out", the in-core copy of the text is just discarded (as it's not writable and there's already a copy on the swap area). > 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! > 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. The point about the merits of compatibility are correct; the general opinion (although there are dissenters) is that "sh" is better for shell script writing for "csh". One reason is, of course, that any V7 or later UNIX system will have "sh", but may not necessarily have "csh", so if you want your shell script to be usable on the widest variety of systems, you should write it for "sh". "csh" has other annoyances, such as the inability to redirect the output of a control construct, that either keep people from using it or make them wish very strongly that they had "ksh"; I know of one "csh" user who hates a lot of its ideosyncracies, exclusively uses "sh" for writing scripts, and would probably ditch "csh" tomorrow if they had a Bourne shell with job control, history, and aliasing - which is exactly what "ksh" is. Any deficiencies of "ksh" relative to "csh" can't be blamed on the Bourne shell having run into "natural limits"; "csh" isn't exactly a super-clean beast which avoids natural limits (it implements control constructs by doing seeks, rather than by reading in the entire construct, parsing it, and then executing it; the latter approach, as used by the Bourne shell, makes a number of things simpler - such as entering control constructs at the terminal - and probably makes it easier to redirect the input or output of a control construct). Mr. Perlman's testimony that "ksh" starts up and runs *faster* than "sh" is, indeed, impressive; Korn's paper on "ksh" in the Toronto USENIX proceedings discusses some of the reasons why this may be. As I suspect he's worked with "ksh" on a regular basis for quite a while, I'll assume his testimony is accurate until proven otherwise. So, until that happens, I'll assume that "ksh" is faster than "sh", not slower. Of course, if AT&T had released it, we'd all be better able to make informed comments about it.... Anybody know what the holdup is? Might like history, aliasing, and job control, but has no interest in "csh", Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
stanwyck@ihuxr.UUCP (Don Stanwyck) (06/04/84)
-------------------------------------------------------------------------------- >All this "ksh is the greatest thing since sliced beer" stuff prompts me to >stick in a contrary opinion. I have had an opportunity to try out ksh. >(An illegally-made outside-Bell copy, I might add, but I wasn't the one who >took it, ported it, or installed it, and it's not on MY machine that I tried >it, so please no anti-piracy flames. I do not support the theft, even though >I did take advantage of it long enough to try ksh across a modem.) > >Anyway, ksh is wonderful IF you don't mind waiting up to 60 seconds for your >character echoes. Ksh is bigger than either than csh or sh, and thus tends >to swap out more often (and takes longer to swap). If you run in "vi" mode, >you will quickly find out that it's not a lot more convenient than the csh >history mechanism. 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. > > Geoff Kuenning : Callan Data Systems : ...!ihnp4!wlbr!callan!geoff -------------------------------------------------------------------------------- As one who uses ksh constantly (in vi mode), I take issue with Geoff. It is faster (has been benchmarked as such), and is much nicer than any other shell I have tried. I suppose that when someone makes an illegal copies, hacks it up into an unsupported tool, tries it and it workds poorly - they just got what they deserved. They shouldn't then flame at the thing when it probably doesn't even resemble the original to any real extent anymore. Geoff: If you really don't support the stealing of software, call AT&T or your local police and report the theft. Otherwise you are now an accessory to the crime, in that you have knowledge of it, but have not reported it. -- ________ ( ) Don Stanwyck @( o o )@ 312-979-3062 ( || ) Cornet-367-3062 ( \__/ ) ihnp4!ihuxr!stanwyck (______) Bell Labs @ Naperville, IL
hart@cp1.UUCP (06/05/84)
You must have something wrong!!!! I use ksh
and it beats the pants off bourne shell. i can't
say anything about csh, but from what I hear
its' no match. Maybe one of the BTL types can
pick up on this.
--
======================================================================
signed: Rod Hart (wa3mez)
Chesapeake & Potomac Tel. Co.
Bell Atlantic Inc.
Silver Spring, Md.
gamma!cp1!hart - umcp-cs!cp1!hart - aplvax!cp1!hart
======================================================================rjs@bonnie.UUCP (Robert Snyder) (06/05/84)
Geoff Kuenning may have had poor character echo time with ksh, but I have been using ksh as my default shell and have had no problems with echo time. (This is on System V Release 2). I run ksh in emacs mode and in general, characters echo immediately. There is one case where this is not true and may be what Geoff was experiencing. If you insert characters at the beginning of a long command, ksh rewrites the entire command every character. This is so it doesn't have to depend on the existence of special terminal capabilities. Robert Snyder clyde!bonnie!rjs
geoff@callan.UUCP (Geoff Kuenning) (06/10/84)
Ah, the flames! I haven't been so warm since I fell into the Mauna Loa's crater... Other references, just before completeness, and because I am not sure of the header reference format when I have more than a line's worth: <1109@ihuxr.UUCP>, <110@bonnie.UUCP>, <694@cp1.UUCP>, <694@cp1.UUCP> Now, to the comments. Several people pointed out that a pirated copy of ksh does not necessarily reflect Dave Korn's best efforts. Good point, and one that I hadn't thought of. The version I tried used "$." for the last parameter of the previous command; somebody mentioned "$_" for the same thing. This would certainly indicate that I didn't try the same version that person uses. I believe that the path by which the pirated copy of ksh left AT&T was under the arm of a departing employee who couldn't bear to give up ksh; this too would also tend to indicate a less than up-to-date version. As to character echoing being slow, I have to confess I don't understand how people misunderstood my original article (even after rereading it), but clearly I failed to communicate completely. I do not have any problem with echo delays as long as ksh is swapped in (even when inserting at the beginning of a long line). My only objection is to the long delays one must necessarily experience when ksh is swapped out while I am typing. As to size and tendency to swap: I fear I did not do enough careful research during my experiments. I *DID* run size on ksh and csh and found csh around 55K versus ksh's 85K (if I remember correctly), but I didn't think to run ps and check dynamic sizes. All I can say abount swapping is that ksh observably swapped out a lot (and it was pretty obvious due to the echo problem). When I typed ^D and returned to csh, the swapping problem went away. Maybe there was a heavy load that just happened to go away at the same time (I doubt it). I think ulysses!gsp's (Gary Perlman) comparison with a pirated Rolex is a more likely explanation. I should mention the configuration of the machine I tried ksh on. It was a 68K (I think 8MHz, no wait states), with (again I think) 3/4 meg of memory (some with wait states) and a *SLOW* 5-1/4" winnie that served as root, user, and swap (how's that for overusing a disk?). I am certain that the smallness of this machine contributed to my problems. (One of our people here also pointed out that on a heavily-loaded Vax, a shared-text ksh will actually be LESS likely to swap out, since *somebody* always will be needing action from it). As to the preferability of sh/ksh for programming over csh: I am not qualified to have an opinion, since I have never written a significant sh/ksh script. I do know that ksh is clearly superior to csh in many respects (e.g., local functions, fewer nasty surprises). I also know that I am in love with the csh array processing (how about it, Dave Korn? Have you added that one yet?). Apparently some people have come to the conclusion that I think csh is the greatest thing ever. Let me say this right now: csh *** S T I N K S *** !!! It is inconsistent, ugly, badly human-engineered, inconvenient, slow to start up scripts, buggy, and full of nasty surprises. It also happens to be the shell I use for interaction and for scripts. For interaction, the explanation is simple: aliases and history. For scripts, I learned how to write csh scripts (and it was PAINFUL) because that was the shell I knew how to use, and it never occurred to me that sh might be better for scripts even though csh is a better interactive shell. By the time I found out (at Korn's Toronto talk) that most people prefer sh for programming, I was an expert csh script writer (at this point, I can do almost anything in csh, although of course many things are harder than in sh/ksh). Since then, I have not written many long scripts, and the ones I have written have been under time pressure and have been within csh's capabilities, so I have not yet made the effort to learn Bourne shell programming. I have promised myself that I will learn it someday, but it probably won't be while I'm working for a company this small. Now, to answer some specific comments: From ulysses!gsp (Gary Perlman): >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. Really, Gary, are personal attacks necessary just because you know Dave and happen to like his program? Dave made a design decision to try to maintain 100% compatibility with the Bourne shell, presumably so people could replace the Bourne shell with ksh rather than having to hassle with the famous "which shell should run this script" problem. This is a completely defensible design decision. It happens to be one that I disagree with, because I think that it locked him into a lot of things that are very clumsy and kludgey (e.g., the implementation of Bourne shell facilities such as 'echo' as special built-in aliases). I have no knowledge of Dave Korn's design abilities, but I would sure like to see *somebody* who is a *good* designer (especially from the human-engineering standpoint, which is almost a completely separate criterion from internal design) come up with a from-scratch shell. >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 Maybe you could let me in on your mind-reading methods? I only listed two explicit objections: dislike of the performance when it swaps out, and dislike of the compromises Korn had to make to maintain Bourne shell compatibility. How do you get these three accusations from those dislikes? >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. I unquestionably jumped the gun in the sense that I did not have the opportunity to try ksh for 6 months as I would like to. My comments were simply an attempt to promote discussion and provide a "devil's-advocate" view, which they did with a vengeance. As to "remarkable support" proving that a software product's problems are due to a particular environment, (1) I never said that I would dislike ksh on a high-performance computer, and (2) even a lousy product (which ksh most definitely is not) can gain remarkable support if it is the best (or only) solution available (IBM still sells OS/370, don't they?). From rlgvax!guy (Guy Harris): >"vi" is >a hefty chunk bigger than "csh" or "ksh", so it may suffer even worse on a >memory-loaded system (although, on a paging system, it might not if its >working set isn't bigger than "csh"s). Yup. I don't use either, although that is more due to human engineering (or rather the lack of it) than performance. Perhaps if I were a regular vi user I would have found ksh's swapping comparable to vi's and been less bothered (as well as being willing to use the better-performing vi mode, though). Guy also includes an excellent discussion about the startup costs of various programs due to fork and vfork which I won't repeat, since I have nothing to add. He is one person who understands how UNIX works. >Any deficiencies of "ksh" relative to "csh" can't be blamed on the Bourne >shell having run into "natural limits"; "csh" isn't exactly a super-clean >beast... I gave my opinion of "csh" above. My reference to "natural limits" was based on my opinion that Korn should have started from scratch, rather than maintaining compatibility. My evidence for these limits is the fact that in many cases Dave had to make a rather kludgey decision to maintain compatibility in the face of his goal of making a much better shell. From ihuxr!stanwyck (Don Stanwyck): >As one who uses ksh constantly (in vi mode), I take issue with Geoff. It is >faster (has been benchmarked as such), and is much nicer than any other shell >I have tried...(Don also points out that one shouldn't judge a program from >a hacked/pirated copy. You didn't mention if you had tried csh (not that I care--I would like ksh if I could use it in a reasonable performance situation). I discussed the hardware configuration above. >Geoff: If you really don't support the stealing of software, call AT&T or >your local police and report the theft. Otherwise you are now an accessory to >the crime, in that you have knowledge of it, but have not reported it. You embarrass me in public, Don. (I presume the "local police" part is a joke). Your point is 100% accurate. I could make a lot of noise about how I don't feel obligated to do AT&T's policing for them, but this would be incredibly hypocritical, since I would certainly report a breaking-and-entering if I saw one. The only defense I can make is that as far as I know, the thief is not offering ksh for sale or otherwise making a profit on it. This is not a very good defense, since ksh is a trade secret (not copyrighted) and thus is not covered under the "fair-use" provisions, and one can certainly argue persuasively that the theft seriously jeapoardizes the trade secret. About all I can say is that I am not eager to be a tattle-tale, and I do not yet see that any damage has been done to AT&T. I know for a fact that the site where I tried it will be one of the first to receive a legal copy of ksh when AT&T does finally distribute it, and I feel that this makes the theft less injurious to AT&T. However, to remain consistent with positions I have taken in the past on the subject of software protection, I feel obligated to make the following offer: if I receive enough MAILED comments from people (inside or outside AT&T) saying that they think it is my moral duty to identify the culprit, I will give AT&T all of the information that I have on the theft (I do not know the name of the thief; I do know the place where he or she went when he/she left AT&T). Since AT&T is such a large organization, I would appreciate it if one of you internal types could give me a uucp address or a phone number to tattle to in your "please tell" message. I will not identify the thief or the site in public; I feel that this is AT&T's prerogative. (Polite) comments were also made by Robert Snyder (bonnie!rjs) and Rod Hart (cp1!hart), but I think I have already addressed what they had to say. I apologize for the length of this; I hope I have cleared up some of the misunderstandings from my original note. Let's continue discussing the pro's and con's of ksh; since Korn is apparently still improving it, there is a real opportunity to add still more value to it before too much of the world gets locked into it. Perhaps, to promote discussion, somebody inside AT&T could post a copy of the manual page (with copyright notice) so us outsiders could at least discuss it theoretically? Oh, and one last thing: you may get the impression that I hate ALL software (since I have mentioned dislikes for csh, vi, and some aspects of ksh's design). You aren't actually off by that much. There are actually software packages I like a lot (DEC EDT V2 comes to mind), but I can see room for improvement in almost everything I use. I am never satisfied with the tools I have when I can see that something better is possible. I make no apology for this attitude; I think that the "I'm not happy with this one, let's make something better" approach is the reason UNIX exists. (And although I have *many* complaints about UNIX, just try to convince me there is a better operating system/utility package in the world for software development.) Geoff Kuenning Callan Data Systems ...!ihnp4!wlbr!callan!geoff