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