svn commit: r337826 - stable/11/bin/ls

[Warner Losh]

On Wed, Aug 15, 2018 at 4:28 PM, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Aug 15, 2018 at 2:41 PM, Rodney W. Grimes <
> freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>
>> > On Wed, Aug 15, 2018 at 2:28 PM, Ian Lepore <ian at freebsd.org> wrote:
>> >
>> > > On Wed, 2018-08-15 at 13:26 -0700, Rodney W. Grimes wrote:
>> > > > >
>> > > > > Will backing out the MFC and leaving this a 12.0 feature end this?
>> > > > =(
>> > > >
>> > > > Sadly no, as the person responded with that reaction when
>> > > > they installed 12.0-ALPHA :-(.
>> > >
>> > > So one whiner can demand of the project that any new feature be
>> removed
>> > > before a new release is made?
>> > >
>> >
>> > This is a good change. I don't see why people are so fussed about it...
>> For
>> > people fighting colored environments a simple unsetenv COLORTERM seems
>> to
>> > solve this problem no only on FreeBSD but for any other system they have
>> > access to...
>>
>> This is exactly the dismissive attitude by FreeBSD developers that
>> I was speaking to in my reply to Ian.
>>
>
> I see how it disagrees with you, but it's not dismissive. It's just asking
> for better data to support your view given that in general when all systems
> do X when Y happens, except FreeBSD, we generally make FreeBSD do X when Y
> unless there's a compelling reason not to. I've not seen a compelling
> reason not to yet.
>
> Basically, why should this be different than our general pattern of being
> in line with industry standards?
>
>
It has been pointed out privately to me that I was being dismissive in the
second sentence. I accept that. I'd like to apologize for that.

I just took a close look at both gnu coretuils' ls code and our ls code.
There's one minor difference in behavior. With gnu ls, if COLORTERM is
empty, it will be ignored. With our code, we'll assume an empty value means
to use colors. That difference should be fixed. This difference is clear if
you look at the unit-tests from coreutils ls as well.

I'll leave for others to debate the meaning of 'standard behavior' and just
focus on what gnu ls does, because that's what Linux users expect, and that
is what the fix was designed to implement. There's a wide variety of
terminals that set this, however. For info see https://gist.
github.com/XVilka/8346728 which goes into detail about it wrt
COLORTERM=truecolor, but is good reading.

I have a patch to make the behavior the same that I've shared that fixes
this, though it's a bit ugly.

There's also -color=xxx in gnu ls that would be a more complete solution,
but our current ls doesn't have long options at all, so it's more of a
heavy lift to merge that functionality into our ls.

Warner