On 4/19/06, James Carlson <james.d.carlson at sun.com> wrote: > April Chin writes: > > A suggestion from a PSARC member was to keep /bin/ksh (Solaris's > > ksh) as is, until it is replaced by ksh93, rather than introducing > > these new obscure names for Solaris's ksh. Then when ksh93 becomes > > /bin/ksh, > > to move Solaris's ksh to a separate package (not part of the main package > > clusters). > > Actually, I believe my suggestion was to *remove* Sun's stale ksh > implementation as soon as ksh93 is capable of replacing it. Ship > /bin/ksh as ksh93 and don't look back. > > I don't believe that we really need to keep around a museum piece like > this. /bin/oksh would be just a relic, entirely superseded by ksh93 > installed as /bin/ksh. For what reason would anyone want to reminisce > with the old ksh implementation? > > If it's really the case that ksh93 is "risky" to drop into place as > /bin/ksh, and that's what we're trying to mitigate, then we ought to > think long and hard about doing it in the first place.
Which could have devastating effects on software vendors - and I think a couple of administrators will complain the moment this happens, too. Solaris ksh has become an UNACCEPTABLE BURDEN, requiring twice the development and testing workload for each change to our shell scripts. i.e. for normal Unix versions and the special case called Solaris. It also prevents us from allowing customers to share the application directory via NFS properly or support Solaris with the demo/update CD. We managed to implement such features even for obscure versions of Unix such as Linux and Mac OSX - Solaris customers are EXCLUDED from that list as support for this would require specific workarounds which we - IMO - are no longer WILLING to support. The keyword is INTEROPERABILITY, an area where I think Sun still has some lessons to learn. Irek
