Roland Mainz 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.
>
> Which name and ksh versions do you mean ? Current Solaris ksh or ksh93 ?
The "obscure names" were "oksh" and "nksh." I don't think either
exists on any other platform.
> Well, I was thinking about the following scheme:
> - Scripts which need explicitly the old Solaris ksh behaviour use
> #!/bin/oksh
> - Scripts which need explicitly ksh93 use #!/bin/ksh93
> - #!/bin/ksh can be either ksh93 or old Solaris ksh depending on which
> OpenSolaris distribution is used
I think that's actually a viable solution. I can't say I buy oksh as
a work-around for broken scripts, but as part of a distribution choice
(akin to using SVr4 packaging or RPM), it makes sense to me.
To get this rolling, I think there are at least two important
components that have to be set out for architectural review. These
are:
1. The oksh+ksh93 paths, and the delivery of ksh as a link. This
part should describe the constraints that distributions other
than Solaris will face, but it sounds doable.
2. The longer-term plan. This should describe how we eventually get
to the hoped-for world in which only one ksh exists, and that ksh
is the newest one possible. (What steps are expected to happen?
What's the next one? What do users see as these steps are
taken?)
The ARC will want to see both, in as much as the details are known, so
that it's clear that we have a path forward. Merely integrating ksh93
and oksh and then walking away would not solve the whole problem.
There's an interesting issue buried here that I don't think has been
addressed before and that I think ought to be brought up for
discussion during that ARC review: how do we handle architectural
issues that are significant for just one Open Solaris distribution?
It seems likely that since distributions other than Sun's own don't
have the support baggage of the old SunOS days, we'll likely have more
split cases like this in the future.
> ksh to work properly, making it impossible for them to switch to ksh93 -
> and the libraries provided by ksh93 (e.g. libast, libshell, etc.) are
> needed to fix |libc::wordexp()| so we are in a chicken&egg-like
> situation here (see
> http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-April/000227.html
> how I plan to fix that).
I don't think that's a chicken-and-egg problem at all. Nothing is
particularly stopping the integration of ksh93 libraries. The
libraries themselves aren't /usr/bin/ksh.
So, one possible plan (I'm not advocating this; just thinking out
loud) would be to integrate the ksh93 libraries now. Next, rewrite
wordexp so that it's not so ugly. Finally, switch /usr/bin/ksh to be
ksh93. Three sequential steps, which could be combined as desired.
> > I can sponsor the change and make the necessary changes to the closed
> > ksh source for you. Introducing the new links would likely be a
> > "fast-track" (simple) case for PSARC.
>
> Yes... but it may also be a good idea to think about backporting them to
> Solaris 10 and Solaris 9 since (for example) some products like Sun
> Studio are supported on more than one OS version. If these products then
> have scripts which require explicitly the old Solaris ksh it could be
> tricky to share them via NFS as /bin/oksh is not available on older
> versions (IMO the backport to older OS versions is very easy since it
> only involves creating the hard link from /bin/ksh to /bin/oksh).
If we can avoid this step, it'd really be quite helpful.
--
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
