James Carlson 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?
As described in the other postings: We think this is needed as a "safety net". By design ksh93 is not fully backwards-compatible to get rid of very ugly (design) issues in ksh88. Software-vendors should be encouraged to test and adjust (if neccesary) their scripts (usually this porting is not required if the scripts are running on multiple platforms so only those products are affected which were written specifically for Solaris) but there should be a way to do the adjustment quickly (e.g. via switching from #!/bin/ksh to #!/bin/oksh to give the software developers enougth time to port their products (that's also the reason why I asked in http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-April/000229.html to backport the #!/bin/oksh naming scheme to Solaris 10 and 9, e.g. allow a smooth and painless transition). > 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. See my comment above. Software which already handles different platforms should have little or no problems with ksh93 - only those scripts which are specifically written (or contain workarounds (and only do platform tests via "uname" or install Solaris-specific scripts on Solaris and a normal script for all other OSes with normal versions of ksh)) for Solaris ksh (which is some very special breed and not even ksh88 compatible!) _may_ need adjustments. Again: _MAY_. The full impact of the change can really only be measued if we give the OpenSolaris community a OS/Net vesion where they can safely put ksh93 into /bin/ksh and try what happens then (this has already been tried in a smaller scale with AFAIK two of the OpenSolaris distributions with good results and very good feedback (except the inetd hickup which is simply a direct results of the |libc::wordexp()| problem)). [snip] > > - 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. See my other postings about how I intend to fix |libc::wordexp()| (e.g. http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-April/000227.html). The proposed patch is just the first step to allow a safe+smooth transition between the single steps described in http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-April/000227.html and allow some time between them (for example one or two OpenSolaris build versions) to allow the community to test each step for regressions. > If that doesn't happen, then I'd recommend fixing ksh93 so that it > supports the -^E nonsense that wordexp requires. Ugh... please no (unless you can convince the ksh93 upstream that this is a good idea :-) ). > Carrying the old > shell around just to support wordexp design flaws seems like the worst > of all possible worlds. I agree. However we need a way to get ksh93 into position first to make the required librares (libast, libshell etc.) available in OS/Net - and that means the current Solaris ksh needs a new place before that point. We could do that all in one step, however I consider that slightly more risky (for example we would have to patch libc AND add new libraries+binaries in one step) - I would prefer the "bankers"-algorithm style which moves from one safe position to another safe position (and let the community test each single step/position) ... :-) ---- bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
