Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!terminus!rolls!mtuxo!mtgzz!avr
From: avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed)
Newsgroups: comp.unix.wizards
Subject: Re: ksh incompatabilities with sh?
Summary: aliases and function names in conflict with (1)
Message-ID: <4120@mtgzz.UUCP>
Date: 24 May 88 23:53:02 GMT
References: <2599@usceast.UUCP> <2601@usceast.UUCP> <4402@vdsvax.steinmetz.ge.com> <4627@hoptoad.uucp>
Organization: AT&T, Middletown NJ
Lines: 28

In article <4627@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes:
< > > 	(okay - you could rename ksh to sh)
< 
< guy@gorodish.Sun.COM (Guy Harris) wrote:
< > Well, no, you really can't, not always.  There are supposedly a few real live
< > incompatibilities that may break some scripts.
< 
< I have heard this too, over the years, and would like real
< documentation on what's wrong.  Are there gross bugs in "sh" that ksh
< is too polite to perpetuate, but which users depend upon?  It would
< seem the best course to fix the ksh to match the sh in all respects,
< rename it to /bin/sh, and throw away the old sh.  I thought that was
< the original idea; what happened?

All the cases of "ksh breaking scripts" I've ever come across were due
to name conflict between standard utilities expected by the script, such
as grep(1), and user-defined aliases and functions. In one not atypical
case, a user who did not like case sensitivity had

	alias -x grep='/bin/grep -i'

in her ksh $ENV file. Then scripts that depend on the standard
case-sensitive behavior of grep, of which there are many, would break
under ksh, but run fine with sh, which doesn't have aliases. I advised
her to change this alias to "mygrep" instead of just "grep", and presto,
her shell scripts started to work with ksh as with sh, just faster.

				Adam Reed (mtgzz!avr)