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.
> - 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.
If Solaris would follow the ksh93 development more closely in the
future, it would definitively have a less stable shell in that
sense.
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.
> 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?
> - Better performance and lower footprint: ksh93 does not only perform
> better than current Solaris ksh - the concept of sharing most of the
> code between various versions of ksh (/usr/bin/ksh, profile shells,
> dtksh, dbx etc.) via libshell.so should also reduce the overall resource
> (memory) usage a lot...
I doubt that. First, ksh93 is at least four times as large as ksh88
(as far as I can see mainly because it reimplements almost the
entire libc functionality). Second, memory usage is not really an
issue here anyway; we are talking about a few megabytes, at most.
What can be much more of an issue is the size of the executable
file because it directly affects the storage requirements even
of a stripped-down distribution e.g. for embedded systems.
> - 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.
> 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."
> - 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?
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.
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 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.
So please release both ksh88 and ksh93 as open source and let
people choose their preference on their own.
Gunnar
