KSH portability

[Stephen J. Friedl]

In article <4063 at mtgzz.UUCP>, avr at mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes:
> In article <631 at vsi.UUCP>, friedl at vsi.UUCP (Stephen J. Friedl) writes:
> > 
> > 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. [...] In my book, ksh is THE paradigm of maximum portability.
> Either you have had an experience you ought to tell us more about, or
> you owe Dave Korn a public apology.

The version I worked with was ksh from the Toolchest in Fall 1986
on a friend's 3B5.  We were going through it in the hopes of
adding some features, so we took a lint pass over the code as a
start; I usually do this with code I'm about to tear into.

Lint did not paint a pretty picture.  Uncast NULL pointer
arguments to functions, functions that return(e) and return,
pointer-returning functions not declared before their use,
and expressions like (vague recollection here):

        *p = movstr(*q++, *p++);   /* undefined eval order */

It did not take us very long to realize that we really didn't
want to tackle this and later we bought Aspen's product for uport
on an AT rather than even try it ourselves; I wonder if anybody
from Aspen could comment on this port?

I've not seen ksh source in a long while, and things may have
changed for the better by now.  It strikes me that a cleanup of
this version of ksh would really be a big job (but then ksh-i was
probably a big job too).

Software quality can be measured in a lot of ways, and the
outside view and the inside view may be radically different.  I
use ksh every day and cannot imagine living without it, but that
version of ksh was not the paradigm of maximum portability.

-- 
Steve Friedl    V-Systems, Inc. (714) 545-6442    3B2-kind-of-guy
friedl at vsi.com    {backbones}!vsi.com!friedl   attmail!vsi!friedl