Xref: utzoo comp.unix.questions:6962 comp.unix.wizards:8384 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!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 Summary: to lint or not to lint Message-ID: <13059@tut.cis.ohio-state.edu> Date: 11 May 88 21:01:36 GMT References: <295@cmtl01.UUCP> <12142@tut.cis.ohio-state.edu> <631@vsi.UUCP> <52399@sun.uucp> Organization: Ohio State Computer & Info Science Lines: 24 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@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)