Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 beta 3/9/83; site callan.UUCP Path: utzoo!watmath!clyde!burl!hou3c!hocda!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!trwrb!scgvaxd!wlbr!callan!geoff From: geoff@callan.UUCP (Geoff Kuenning) Newsgroups: net.unix Subject: Re: I, for one, tried ksh and don't like it Message-ID: <166@callan.UUCP> Date: Sat, 9-Jun-84 21:42:55 EDT Article-I.D.: callan.166 Posted: Sat Jun 9 21:42:55 1984 Date-Received: Wed, 13-Jun-84 01:44:37 EDT References: <161@callan.UUCP>, <866@ulysses.UUCP>, <1987@rlgvax.UUCP> Organization: Callan Data Systems, Westlake Village, CA Lines: 207 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