ksh incompatabilities with sh?

[XMRP50000[jcm]-a.v.reed]

In article <4627 at hoptoad.uucp>, gnu at hoptoad.uucp (John Gilmore) writes:
< > > 	(okay - you could rename ksh to sh)
< 
< guy at 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)