KSH portability

[Guy Harris]

> > Note that porting ksh is not at all a task for the novice; it is
> > not (to put it politely) "maximally portable".
> 
> What experience is that comment based on? My personal toolkit is
> based on ksh, and so I've brought ksh to every UNIX box I've worked
> on. It was NEVER more than one day's work; in most cases a simple
> make is enough to bring it up and have it work to the man page.

What version of the Korn shell is your experience based on?  The latest "ksh-i"
may have fixed some of the problems; however:

	1) The previous version assumes that you can catch SIGSEGV and have
	   the SIGSEGV handler grow the data space and return, causing the
	   faulting instruction to be reexecuted.

	   This is *not* true on a number of machines.  The 68000 can't support
	   this in general, and the 68010/68020/etc. make it a bit of work to
	   support it.

	   This one isn't Dave Korn's fault; a while ago, I think John Mashey
	   claimed that he pushed Steve Bourne to use this "feature" in the
	   Bourne shell, and the Korn shell inherited it from there.

	   We fixed this a while ago in the Sun version of the Bourne shell;
	   the fixes generally apply to the Korn shell as well.  I tried
	   running a fixed and non-fixed version of the S5R2 Bourne shell on a
	   3B2 (on which the aforementioned trick does work); I did something
	   such as

		echo `cat *.c`

	   in the Bourne shell source directory, and found that the changes,
	   which consisted largely of explicit checks to see if the data space
	   needed to be expanded, didn't make any noticeable performance
	   difference.

	   I have heard that this is fixed in "ksh-i".

	2) The previous version does not use "getpwnam" to get home directories
	   when expanding "~username" constructs.  It does so to avoid doing
	   "malloc"s in certain places; "malloc" in those places doesn't work
	   because of the, umm, *quirky* way the Bourne (and Korn) shells
	   manage the heap.

	   This doesn't work very well on systems that have Yellow Pages, or in
	   fact on any system where a simple-minded scan of "/etc/passwd" won't
	   necessary find all the entries that "getpwent", "getpwnam", etc.
	   would find.

	3) The previous version assumed that the "_iob" structures for standard
	   I/O were in one long contiguous block.  The 4.3BSD standard I/O
	   library puts the first 30 or so into such a block, and "malloc"s
	   additional ones.