KSH portability

[Lawrence V. Cipriani]

Guy Harris writes:
>There may be cases where making it completely free of "lint" complaints may
>cause problems; however, all the problems listed above can be fixed without
>impairing portability, and the first of them, at least, is a *real* problem on
>*many* implementations.

Okay, if there is another ksh release and if I get to beta test it,
I will lint the code and fix as many of the bugs as I can.

>The only way that making something portable is made difficult by differences
>in *implementations* is if you're depending on particular details of the
>implementation.  If you want to make code portable, you avoid doing that
>wherever possible; you code to the specification, not the implementation.

I think Korn placed a big emphasis on ksh's performance.  I would gladly
give up a bit of portability to gain performance,  Korn may feel the same.
I would rather have portability and high performance but I'll give up
portability if that was necessary.  To me, it is more important to make ksh
users happy than ksh hackers.
-- 
Larry Cipriani, AT&T Network Systems and Ohio State University
Domain: lvc at tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)