On 2/14/06, Gunnar Ritter <gunnarr at acm.org> wrote:
> Roland Mainz <roland.mainz at nrubsig.org> wrote:
>
> > - Move current /usr/bin/ksh to /usr/bin/oksh (now called "old" korn
> > shell) [...]
> > - Put ksh93 into /usr/bin/nksh ("new" korn shell. ksh93 MUST NOT be
> > placed to /usr/bin/ksh93 - arguments can be listed here but that is
> > AFAIK outside the scope of this mail))
>
> To the contrary, there should be /usr/bin/ksh88 and /usr/bin/ksh93.
> Names should be chosen for their descriptive clearness, not for
> political reasons.
Solaris /usr/bin/ksh is not compatible to ksh88, naming it
/usr/bin/ksh88 is therefore even more confusing.
>
> > - ksh93 is under active development - there is an "upstream" (David
> > Korn, the AST community and others) who are working on it, doing
> > bugfixing, enhancements, patch integration etc.
>
> This may or may not be seen as an advantage. One of the finest
> properties of the current Solaris user space is that one always
> knows what one can expect. Certainly, this sometimes means that
> one expects bugs, but a known bug (usually with a known workaround)
> is better than a surprise at the next system update.
Yes, I see the advantage here. Current /usr/bin/ksh is buggy (see
bugs.opensolaris.org), nonstandard and lacks significant features
available in the ksh binaries shipped with other *decent* Unix
operating systems.
Having the current version of /usr/bin/ksh in Solaris is justification
enough to say that Solaris is not a decent operating system.
>
> If Solaris would follow the ksh93 development more closely in the
> future, it would definitively have a less stable shell in that
> sense.
Could you please clarify that with more points?
>
> Also, looking at the long list of bug fixes and changes in recent
> versions of ksh93: Yes, there are many fixes indeed, but when can
> one expect a stable release? Issues like
>
> 05-09-15 A for/while loop optimizer bug in which $OPTIND was not
> correctly expanded has been fixed.
> 05-06-24 A race condition which could cause the exit status to get lost
> on some fast systems has been fixed.
>
> do not really make me trust in the stability of ksh93.
Did you follow the bugs in Solaris ksh, too? The patch documentary for
Solaris /usr/bin/ksh is full of issues which are more scaring than
what you have listed above.
>
> > Solaris ksh is Solaris-only - it has no "upstream" and Sun engineers
> > have all the burden of maintaing it. I've heared lots of complains in
> > the past about this maintaince nightmare called /usr/bin/ksh from Sun
> > engineers... ;-(
> > And Sun's bug database is still full of unfixed bugs which no longer
> > exist in ksh93...
> > The introduction of ksh93 (and depreciation of /usr/bin/oksh (= current
> > Solaris /usr/bin/ksh)) would be another good opportuniny for Sun to save
> > lots of engineering time in the long term.
>
> I doubt that. ksh93 has bugs on its own. Sun will have the choice to
> either wait for an upstream bug fix or to get its engineers to handle
> it in-house. But then, have a look at the ksh93 source code. In case
> the ksh88 code should really be a nightmare, what is the ksh93 code
> with its close integration to large libraries such as libast and its
> very special build environment?
Invalid arguments.
The build system can be worked around or fixed as in MacOS X. libast
may be statically linked if it does not make sense to make it a public
API. The only thing which is likely going to be exposed is libshell.
[...]
> > - Greater interoperability between operating systems: Currently Linux
> > and some of the other Unix derivates (AFAIK AIX) ship ksh93 as
> > /usr/bin/ksh
>
> This is not an issue in my opinion. For a complex shell script,
> it is relatively easy to also create an installation script which
> finds a matching shell.
*IF* there is a matching shell (bash does not count in my opinion).
>
> > And (sales) people would no longer be able to refer to Solaris as
> > an "outdated" operating system ("... Solaris is stuck in the 80' of the
> > last century - just check the version of ksh they're shipping..." etc.).
>
> No, they could say instead, "look, Solaris now updates its critical
> system binaries as often as Linux distributions do, resulting in
> comparable trouble at every system update."
The trouble is already there - in the form of companies like ours who
are now very close to drop it's entire Solaris port due lack of
cooperation by Sun in this matter.
And Felix also had a *very* valid argument: Interoperability between
Solaris ksh and ksh on other Unix versions tends to be very shallow at
best. Think about it. It started to hurt users.
>
> > - There would be no need to make the old ksh88 OpenSource (which also
> > means: Less work for the lawyers... :-) ).
>
> I do not understand that issue anyway. As far as I know, ksh93
> is a derivative of the ksh88 code. If AT&T allows to ship the
> ksh93 code, why would there any legal reason not to ship the
> ksh88 code? Or is there rather another reason behind this?
Lawyers. Novell holds the rights now. And guess what Novell Linux
ships: ksh93 as /usr/bin/ksh
>
> What I can feel in this debate is a lot of politics. There are
> obviously people who want to deploy ksh93 for many good reasons.
> I do not want to oppose against that; I think it would be a
> very good thing to deliver /usr/bin/ksh93 for those who want
> to use it.
And then? Do you really want to *force* the community to be stuck in
the past with a ksh version which is a usability, interoperability,
maintainer and portability nightmare?
>
> But I do really not like the fact that these people also want
> to prevent others to continue to use ksh88. In my experience,
> Solaris ksh is a stable shell
HAHAHAHA. Read the patch documentary.
> that has always served me well.
> I would not like to see it dropped; to the contrary, I would
> like to see an open source version of it.
No, thanks.
>
> So please release both ksh88 and ksh93 as open source and let
> people choose their preference on their own.
What is your proposal ? To release ancient code which is not
compatible to anything, causing a significant maintainer,
interoperability and portability burden to the community?
No, thanks.
The current Solaris community does *not* have the power to handle two
versions of ksh. We either have to decide whether we want to go
forward (ksh93) or stay in the past (current Solaris /usr/bin/ksh).
Please let the current Solaris /usr/bin/ksh die.
Irek
