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 :-)