> On 7/28/06, April Chin <April.Chin at eng.sun.com> wrote:
>> I would prefer any proposed /usr/bin/sh migration be a follow-up
>> to /usr/bin/ksh migration. Changing /usr/bin/sh may prove more
>> difficult but
>> then again the /usr/bin/ksh work may pave the way.
Martin Schaffstall wrote:
> April, it may be easier than you think. I have talked to Henk and we
> think that updating /bin/sh to ksh93 may break much less scripts than
> an update of /bin/ksh to ksh93
Martin,
That's true, but try to realise there's is more to /bin/sh than just
portability. I came with the original suggestion, and I do think that
having /bin/sh being a POSIX compliant shell would be a good thing in
the end.
The issues:
Engineering Resources
Change takes time - let's do one thing at a time. I was the one who
quipped that replacing /bin/sh with ksh93 would be less controversial
than replacing /bin/ksh. I still believe that, but April has now
committed to this process.
As long as there is progress with /bin/ksh, then let's focus on that.
Compatibility
I'm convinced replacing /bin/sh with ksh93 would hit less glitches
than the replacement of /bin/ksh. ksh93 is a POSIX superset, which
in turn is compatible with traditional Bourne /bin/sh behaviour.
We can say the same for Bash, which is used as /bin/sh in Gnu/Linux.
Performance
ksh93 can run traditional /bin/sh scripts with little or no impact.
Builtins can improve performance, common external routines like
basename() and dirname() can be replaced with inline code ( progname=${0##*/} ).
On the other hand, ksh93 has a larger footprint, and takes more time and
resources
to start up than /bin/sh. (But once you've got the first instance running, that
point would be moot, not?)
Discuss
Regards,
Henk
