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

[Kyle Evans]

On Wed, Aug 15, 2018 at 2:55 PM, Rodney W. Grimes
<freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>> On Wed, Aug 15, 2018 at 2:34 PM, Rodney W. Grimes
>> <freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>> > [ Charset UTF-8 unsupported, converting... ]
>> >> On Wed, Aug 15, 2018 at 12:43 PM, Rodney W. Grimes
>> >> <freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>> >> >
>> >> > From the Linux man page at: http://man7.org/linux/man-pages/man1/ls.1.html
>> >> >
>> >> >        Using color to distinguish file types is disabled both by default and
>> >> >        with --color=never.  With --color=auto, ls emits color codes only
>> >> >        when standard output is connected to a terminal.  The LS_COLORS
>> >> >        environment variable can change the settings.  Use the dircolors
>> >> >        command to set it.
>> >> >
>> >> > Um, so by default we should not be doing any colour... and we are...
>> >> >
>> >>
>> >> I don't recall making any argument that we're trying to match GNU
>> >> ls(1) behavior. Furthermore, again, we aren't doing any color by
>> >> default- only when the COLORTERM environment variable is set.
>> >
>> > So we are intentially being different?
>> >
>>
>> No, we are not intentionally being different. See: the next paragraph,
>> where I described that we've now-historically been honoring an
>> environment variable for this and have simply added a more standard
>> name for this variable.
>
> And one that is set by default many more places than the one that
> had been set before, changing behavior people have been seeing for
> a long time, and some of those people did not expect that,
> nor seem to want it either.

Will backing out the MFC and leaving this a 12.0 feature end this? =(

Many changes we make fit the same same description that you just
wrote, perhaps with "many many more places" replaced with "".
Standardization is hard to argue against, leaving one knob to turn
everything off or on and not having to have a profile full of:

LSCOLORS=yes; export LSCOLORS
GREPCOLORS=yes; export GREPCOLORS
DPVCOLORS=yes; export DPVCOLORS
...

I would hazard a guess that most people err to one side or the other:
all the colors or none of the colors.

>>
>> >>
>> >> ls(1) on FreeBSD historically honors -an- environment variable for
>> >> enabling color.
>> >
>> > Short history, long history it had no color support at all.
>>
>> Color support in ls(1) is now old enough to drink having been
>> introduced in 2000- I think that's long enough to call it
>> "historically" here in 2018.
>
> ok, but for 25 years that ls has output in b&w even in
> a colour terminal unless I took action to make it color output.

And still, with a base FreeBSD install, you take action to make it
color output. Some third party software claims COLORTERM for you, and
you should be aware if this is the case. Not all color terminals will
set COLORTERM for you.

>> >> This environment variable is CLICOLOR. This commit
>> >> switched the environment variable honored to the more-standard
>> >> COLORTERM that is honored in other software and set by terminals that
>> >> are generally expected to be used with color.
>> >>
>> >> I'm writing an UPDATING entry for this now to notify these users that
>> >> they should remove COLORTERM from their environment if they do not, in
>> >> fact, want a colored terminal.
>> >
>> > Is that the only way to turn this off?
>> > That may not be desired either.
>> > Atleast GNU ls allows me to force it off on command invocation
>> > with --color=never, do we have an equivelent?
>> >
>>
>> Sure- it gets turned off the same way it got turned on. =)
>
> Well, it now gets turned on when it was not turned on before,
> and as is I now have to completly decolor to decolor ls(1),
> I have no easy knob to turn off colorls only.
>
>> I'm
>> certainly not averse to adding a --color long option, and will do so
>> when I find the time (later today, most likely).
>
> That would help, atleast the annoyed can alias ls ls --color=never.
>

Ok

> NB: from the GNU ls documentation there is a significant performance
> impact with having colorls turned on as you now have to stat every
> file in a directory listing.  Is this also true of the BSD colorls?
>

No clue.