I, for one, tried ksh and don't like it

[Geoff Kuenning]

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 at ihuxr.UUCP>, <110 at bonnie.UUCP>, <694 at cp1.UUCP>, <694 at 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