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. > However, I think we still need to name Solaris's ksh something unique > from /bin/ksh (or at least move it to another directory), even if it You _cannot_ ship different files using the same path name in different packages. That does not work and violates some of the fundamental packaging rules. We can't have two different packages both delivering /usr/bin/ksh but with different bits inside. If we really need to have the old ksh around, it needs a new path along with a new package. But I'd like to see a justification for keeping it at all as part of the ARC materials. > - Do we need any links for /usr/xpg4/bin/sh? Once we've transitioned > to a standard-compliant ksh93, will there be any need for the old version > of the standard-compliant shell? That's a sticky point. For standards-compliance, the path doesn't matter. The standard says nothing about the path you must use to reach the standards-compliant shell. However, we have allowed "cherry-picking" of standards-compliant utilities in the past, and leaving behind a symlink would be extremely low cost, so I think it's the right thing to do. > - Is it necessary to change wordexp() to use /usr/bin/oksh instead of > /usr/bin/ksh? Once ksh93 becomes /usr/bin/ksh, oksh may not be > installed into the Core Solaris cluster (see suggestion above), but > we could look at changing wordexp() to dlopen() of libshell.so or some other > method which uses ksh93. Please consider fixing workexp() to be a less horrible hack. If that doesn't happen, then I'd recommend fixing ksh93 so that it supports the -^E nonsense that wordexp requires. Carrying the old shell around just to support wordexp design flaws seems like the worst of all possible worlds. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
