I mostly agree with what April and Roland are saying below. But, I
believe we are really talking about five shells (/sbin/sh, /usr/bin/sh,
/usr/bin/ksh, /usr/xpg4/bin/sh, and /usr/dt/bin/dtksh) and their
relationship to what will soon be installed as /usr/bin/ksh93.
Since /usr/bin/sh is now just a symlink pointing to /sbin/sh, we only
have to worry about four distinct binaries (and various links to
them). I sincerely hope that we can create an environment where
/usr/bin/ksh93 can replace all of the other four shells. But, until we
fully evaluate the incompatibilities between them and the
specifications that specify their behaviors (SVID3 for /usr/bin/sh,
POSIX for /usr/xpg4/bin/sh, and the man pages for all of them), I don't
think we have enough information to make any commitment now as to
whether all of them can be replaced, and, if so, in what order. We
will be deciding which ones to replace and the replacement order when
we have figured out what incompatibilities exist and how we can address
each of them so they won't affect existing applications.
I don't think it makes much difference for this discussion, but note
also that /usr/bin/sh is not always used by system(), popen(), and
make. /usr/xpg4/bin/sh is used rather than /usr/bin/sh when an
application invoking popen() or system() is running in POSIX mode.
Although I don't see it on the man page, make should use
/usr/xpg4/bin/sh rather than /usr/bin/sh when the .POSIX special target
appears as the first non-comment line in makefile. /usr/xpg4/bin/make
should probably always use /usr/xpg4/bin/sh, but I don't see that on
the man page, either.
- Don
>Date: Thu, 26 Oct 2006 12:54:42 -0700 (PDT)
>From: April Chin <April.Chin at eng.sun.com>
>Subject: Re: [ksh93-integration-discuss] Proposal: Migrating /bin/sh to
ksh93before /bin/ksh
>
>> Date: Tue, 24 Oct 2006 09:55:11 +0200
>> From: Roland Mainz <roland.mainz at nrubsig.org>
>>
>> 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) ... ;-/
>
>This bug was originally closed back in 1997 as "will not fix" because the
>POSIX version of sh is already implemented in /usr/xpg4/bin/sh, which is
>based on ksh88. The Solaris OS has /usr/xpg4/bin and /usr/xpg6/bin
>versions of utilities to deal with incompatible standards-enforced
>behavior with the /usr/bin versions of the utilities.
>
>The compatibility problems with existing customer sh scripts
>and sh scripts in the system were considered too risky.
>
>At this point, we are again considering /bin/sh replacement with ksh93,
>but as Roland says, we are taking it a step at a time, starting with
>replacing /bin/ksh first. I believe the incompatibilities between Bourne
>shell and ksh93 may be greater than those between ksh88 (or rather,
>Solaris's version of ksh88, /bin/ksh) and ksh93, which could make
>the /bin/sh migration more difficult.
>
>> > 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.
>
>With the use of /bin/sh by popen(), system(), and
>make, we will have to be extra careful with the /bin/sh migration...
>any usage of popen(), system(), execvp(), etc. will also need to
>consider any incompatibilities.
>
> April
