Xref: utzoo comp.unix.questions:6908 comp.unix.wizards:8322
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!lvc
From: lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: KSH portability
Message-ID: <12692@tut.cis.ohio-state.edu>
Date: 7 May 88 12:11:21 GMT
References: <295@cmtl01.UUCP> <12142@tut.cis.ohio-state.edu> <631@vsi.UUCP> <4063@mtgzz.UUCP> <645@vsi.UUCP>
Organization: The Ohio State University Dept of Computer and Information Science
Lines: 30

In article <645@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>In article <4063@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes:
>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
Thats some wealthy friend !


>start; I usually do this with code I'm about to tear into.
Likewise.

>Lint did not paint a pretty picture.
I had a conversation with Korn about this once.  He said that
if he made ksh lint free that it would lose portability!  I
was pretty suprised, but I'll believe him.

>It did not take us very long to realize that we really didn't
>want to tackle this ...

I made two changes to ksh, one was a simple change for the default
TMOUT parameter  The other was to reset the IFS to " \t\n" on
startup and to ignore the value inherited from the environment
(I did the same for sh and that was easy to find).  I got the
answer from Korn, since I couldn't figure it out.  Turned out
to be a one liner.

Back to the stdio hassle with ksh, Korn also told me once that
one of the biggest problems in making sh pportable was that the
stdio *implementations* differed so much.  I'm sure he would
have done the "portable thing" if it were possible, but it must
not have been possible.  Isn't all the world System V :-)