Knut Reinert wrote:
>
> Based on the earlier discussion about the migration of /bin/ksh I'm proposing
> to migrate /bin/sh to ksh93 before /bin/ksh. It may prove to be a simpler
> work with fewer political obstacles because the feature set of the Bourne
> shell is smaller than the set of features found in ksh88.
In theory it may be nice - but I would expect that this is much more
difficult than migrating /usr/bin/ksh to ksh93. /usr/bin/sh is used
almost everywhere, ranging from system calls to makefiles and we would
require an even larger amount of testing to get this working (another
problem is that the Bourne shell lives physically in /sbin/sh - which
means any replacement must live in the root filesystem. The original
ksh93-integration prototypes placed ksh93 and it's libraries in "/" but
it was moved to "/usr" as result of the initial ARC case due lack of a
compelling reason ("no buisiness case") and the matching OS/Net Makefile
switch to install ksh93 as /sbin/sh was removed, too (there was no easy
way to conditionally move the libraries around and therefore I removed
the switch)).
I and April selected the path to migrate /usr/bin/ksh (and then
/usr/xpg4/bin/sh (which is based on the same code as the current Solaris
/usr/bin/ksh)) first and then we _may_ look at /usr/bin/sh again.
> Benefits:
> * ksh93 as /bin/sh would provide a POSIX compatible shell
Did you see
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4088172
("*sh* request to have /usr/bin/sh be a POSIX shell") yet ? It's marked
as "Closed, will not be fixed" (I don't know the reason for that, maybe
April, Mike or Casper know the reason) ... ;-/
> * Greater interoperability with other operating systems, including Linux
> * Greater flexibility in script development
> * Reduced maintenance requirements (only one code base instead of two needs
> to be maintained)
> * The project would prepare the path for the larger /bin/ksh migration project
>
> The Bourne shell is lacking POSIX conformance and common extensions available
> on other operating systems makes it a challenge to port even simple
> applications to Solaris.
> This is multiplied by the problem that /bin/sh is the default shell for
> system calls such as popen(3c) and system(3c) or utilities like make(1) which
> cannot be changed to another shell based on a system wide tunable or other
> "easy" solutions to work around the limitations of the Bourne shell.
The issue with /usr/ccs/bin/make is very annoying... it's one of the
main reasons why peojects like Mozilla.org constantly run into problems
with Solaris because the default shell for "make" is /usr/bin/sh ... ;-(
> ksh93 is open source and will be readily available in Solaris as
> /usr/bin/ksh93 soon, allowing community members to contribute fixes,
> resulting in a better quality default shell for Solaris.
>
> In addition to many new features, a couple problems already described in the
> Sun bug database are fixed in ksh93, including:
> * Bug ID: 4088172 *sh* request to have /usr/bin/sh be a POSIX shell
> * Bug ID: 6378708 *sh* could implement non-conflicting posix syntax
> * Bug ID: 6398988 /bin/sh should support $(), just like POSIX
I think the last two (CR# 6398988 and CR# 6378708) qualify for a
WONTFIX. Adding this to a Bourne shell would immediately break the
"configure" scripts which use things like $( ... ) to distinguish
between bourne shell and ksh/bash. Either /usr/bin/sh should be replaced
with a full POSIX shell (like ksh93) _OR_ it should remain at the normal
Bourne shell level. Wasting time with such troublesome extensions (e.g.
CR# 6398988 and CR# 6378708) should be avoided...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
