Darren J Moffat wrote:
> Danek Duvall wrote:
>> /usr/gnu/bin/ls still has functionality that /usr/bin/ls doesn't -- in
>> particular, the colorization is more flexible in the GNU version. I
>> don't
>> want to go back to having to build my own copy just to get the bits
>> that I
>> need.
>>
>> Providing the GNU coreutils is a small burden on Sun, and it's a loss
>> for
>> anyone who actually wants to use and keep up with the GNU bits; it's not
>> clear to me at all how removing these utilities is a win for anyone.
>
> Thanks you said that more eloquently than my attempt.
>
> I think the root architectural problem here is that the default
> installed user/environment has /usr/gnu/bin ahead of /usr/bin in $PATH.
>
> We need to solve that problem instead of dim sum shopping between GNU
> binutils and ksh93 (and any other trolley that passes us by).
>
> So please set a timer on this case it doesn't qualify in my opinion
> for self review and needs to be a fast-track.
Oh, wow. I didn't realize this was self-review. It needs to be a fast
track, indeed.
I'm not a huge fan of keeping two different sets of utilities around.
It would be good to get our ls(1) to be 100% compatible with the GNU
features. Is that the only complaint you have, or are there others?
IMO, continuing to ship these on every install is wasteful. I value my
use of "/bin/tcsh" more than your unusual colorized ls options. Who
should win?
Let me put that another way. I have no problem with these things being
delivered via an IPS repo to some path not in the default (or renamed as
"gls" or somesuch, for example). But I don't think these GNU versions
of utilities should be installed by default, at least not while we are
electing to not install other components that are (IMO) far more useful
because we don't have enough room on the install media.
- Garrett
