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

[Gary Perlman]

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