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

[Guy Harris]

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