On 03/18/10 09:37 AM, Peter Tribble wrote:
> On Thu, Mar 18, 2010 at 3:41 PM, Darren J Moffat
> <darrenm at opensolaris.org>  wrote:
>    
>> 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 ?
>>      
> No. It's explicitly stated that --version in particular is worded differently.
> I've seen configure scripts and applications take apart --version output
> in order to divine version-specific behaviour
>    

If those versions specify a full path, then they'll not see a change.  
It does sound like this is kind of busted.  I can understand why this 
happens though.


>    
>>   If so then I wonder why we are even shipping the GNU
>> ones.
>>      
> Because that's what many users and applications expect. And there's
> a world outside ksh93.
>
>    

I have a couple of opinions about all this, which I'll restate here:

1) In an ideal world, we'd supply (by "default") a single implementation 
of these commands.  It seems like ksh93 is the most well-maintained 
POSIX conforming implementation, and offers all the features people seem 
to want, so that seems like the best choice.

2) /usr/gnu versions would still ship for people who *insist*, but we 
should not be advocating GNU versions in preference to the POSIX 
conforming versions.  /usr/gnu has no place (IMO) on the default user's 
path.  The fact that we put it there at all now is just a crutch to 
workaround the lack of investment in the aging (rotting!) Sun userland 
(ksh93 not included)

3) IMO, the configuration of builtins should be enabled the same way 
that other PATH elements are enabled -- via a new PATH element.  I would 
not mind seeing /usr/ksh93/bin.  This could be prepended to the default 
PATH for new users.  It would provide POSIX conforming (plus any of the 
popular desired features from GNU, BSD, etc.) implementations of 
commands, but would also allow for simple builtins to be used by libcmd 
and ksh93.  Since ksh93 uses libcmd, there would be *zero* functional 
difference apart from the savings of a fork/exec, and everyone would be 
happy.

This whole nonsense IMO, comes about because the ksh93 folks want to 
enable higher performance, but someone decided that /usr/gnu should be 
at the front of default users PATHs.  I think *that* decision was busted.

     -- Garrett

Reply via email to