Roland Mainz writes:
> > 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".
In that case, I think the materials presented for ARC review should
describe this issue in a great amount of detail. Introducing such a
thing is non-trivial.
The specific items I'd want to see in that review are:
- A complete list of the known compatibility issues. (I've seen a
couple of lists, but don't think I've seen a complete one yet.)
- Some discussion of why the incompatibilities are strictly
_required_, and aren't just an artifact of the implementation.
(I.e., "doing X means that Y must fail by design, and Y is a more
important feature" is a good sort of answer, but "maintaining X
was just too hard" likely is not.)
- Some indication of what particular software is likely to fail.
Have we looked at any third party scripting to see if failures
will affect any significant user population? I'm quite willing to
write off "probably never used" features, but less so for things
that we can easily predict will cause widespread problems.
- A description of how the "safety net" might plausibly be used.
I'm not talking about trivial cases here (such as old hacks the
user might have in $HOME/bin), but rather the hard ones, such as
third party code. Just what does a user do?
- Any thoughts about how the problems could be avoided would be
welcome. Have we talked to any third-party software vendors to
get them to migrate? Are there any validation tools ("appcert for
shell scripts?") that could be applied? Is there any way that the
shell could detect these specific cases and log a warning or error
somewhere that might be noticed? (I'm worried about scripts that
are buried several layers deep, behind other scripts and a GUI.
Failure there likely means huge debug expenses for users.)
The underlying issue here is that compatibility isn't just a goal for
Solaris. It's a constraint. As an ARC reviewer, I want to be fully
convinced that when we break things, it is because we have no
plausible alternatives, not just because we think we can do it.
I can't (and won't) speak for other ARC members. You should contact
them if you'd like to find out what they think. Having an inception
review *right NOW* that outlines this project's plans -- even if
they're incomplete -- would be the very best way to do this. I think
the project already has more than enough information for an inception
review. ("ARC early, ARC often.")
However, if I had to guess at it, I'd guess that most of the ARC
member opinion would range from my viewpoint (somewhat liberal on such
issues) towards a more conservative "strict compatibility only" slant.
> 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
This leaves out some significant details:
- What does a user see? How does an end user know that the problem
is a third-party application that needs to be updated rather than
a bug in Solaris that needs to be fixed?
- Just how hard is it to fix these problems "the right way?" If
it's just (say) a week's worth of effort to recode a broken script
to work with the new ksh, perhaps there's no point in providing an
alternative that could (and probably will) be abused. (For most
vendors, the time required to test and deploy a fix -- even
/bin/oksh -- completely dominates the time to fix a problem. And,
like Sun, vendors often stop supporting "old versions," meaning
that some users may well just be out of luck.)
- What demands are placed on an administrator? Using /bin/oksh
means that we'll need patches that introduce this object (or
symlink) on old releases, meaning that vendors in this position
will be forcing their customers through an ugly must-patch-first
(before script is rewritten) to no-patch-needed transition. These
things are often very confusing for users and result in expensive
support calls.
These are all elements of a transition plan, and are related to the
items I've noted for ARC review above.
I don't think there's a free lunch here.
> > 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_.
If people are using uname this way today rather than feature tests
(ugh!) or just avoiding known trouble areas, then that software _will_
break when ksh93 is integrated as /usr/bin/ksh.
> 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)).
I don't see the point in running an experiment here. Users who wish
to do this can already do it themselves with "rm" and "ln." No
special changes are required.
If the point is that we'd like to see all Solaris users forced through
the experiment as well, then I'm really just not sure that the plans
are baked enough.
> > 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 :-) ).
I hope not, too.
> > 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) ... :-)
In that case, it sounds like you're actually advocating my previous
(and not preferred) "option 1:" integrate ksh93 as /usr/bin/ksh93 now,
and attempt the /usr/bin/ksh transition later.
That'd be acceptable (in fact, probably trivial) from an ARC point of
view, but based on previous messages on this thread, it sounds like
"/usr/bin/ksh must always be ksh93 or Solaris is doomed, I tell ya,
doomed" is the prevailing opinion among a vocal set of users. Any
such plan likely has to skate between the requirements of those users
and the Solaris compatibility requirements.
--
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
