On 03/18/10 08:41 AM, Darren J Moffat wrote:
> Maybe I don't understand enough about ksh93 (since I'm a zsh user for
> interactive shell work) but I don't understand what this case is about.
>
> What benefit does this case bring ?
(Note: I'm not the project team, just the ARC sponsor. They may have
different ideas here, so they should respond if appropriate.)
ksh93 already has the code. As I understand it, this change benefits
ksh93 users and scripts, by reducing the total number of fork/exec
calls. It makes use of the common code base that we already have
available. I am not aware of any other benefits.
>
> How does this interact with PSARC/2009/377 in kernel pfexec, maybe it
> doesn't need to and that is an okay answer, when ksh93 is the profile
> shell ?
I don't think this gets involved with that, because the builtins are
only used when a default path search is applied, not when a fully
specified path is used.
>
> Why would I want to use ksh93 builtins if I have /usr/gnu/bin
> explicitly in my path ? Are the ksh93 builtin versions 100%
> compatible in all respects with the GNU ones ? If so then I wonder
> why we are even shipping the GNU ones.
>
My understanding is that yes, the ksh93 ones are fully compatible modulo
some bugs which are fixed in the ksh93 versions. I've always questioned
the idea that we have to ship all GNU tools, instead of modernizing our
own set. I think the idea is to make people who prefer Linux happy.
That said, its possible that the GNU tools will evolve in the future, at
a rate differently than the ksh93 versions do. (At that point, the case
says that the ksh93 version will either be adapted, or they'll stop
supplying the built-in.)
-- Garrett
