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

[Kyle Evans]

On Wed, Aug 15, 2018 at 11:07 AM, Rodney W. Grimes
<freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> On 14 August 2018 at 21:41, Rodney W. Grimes
>> <freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>> >> Author: kevans
>> >> Date: Wed Aug 15 01:29:02 2018
>> >> New Revision: 337826
>> >> URL: https://svnweb.freebsd.org/changeset/base/337826
>> >>
>> >> Log:
>> >>   MFC r337506: ls(1): Enable colors with COLORTERM is set in the environment
>> >>
>> >>   COLORTERM is the de facto standard, while CLICOLOR is generally specific to
>> >>   FreeBSD and ls(1).
>> >
>> > I have already seen one "Who enabled %&*@(#$@) colored ls output in 12?"
>> > Seems that the defaults for xfce terminal is to have COLORTERM.
>>
>> If xfce's default is to request colour via the de-facto environment
>> variable then we should generally honour it -- the answer to the
>> %&*@(#$@) question is "you did, via your terminal's default."
>
> And I pointed that out to them, but it is kinda a POLA, people have
> had to take explicit action to get colorls, that is no longer true
> and that suprises them when they see it.
>

I find the POLA angle kind-of hard to buy, though. Nothing in the base
system offers a way for the default behavior of ls(1) to be altered,
and this whole change is only honoring a de-facto standard for
indicating that a colored terminal is supported and desired.

IMO, one should be aware of how the software they use is affecting
their environment and the kinds of repercussions these changes may
have. This is hardly the first bit of software that respects
COLORTERM, and it surely won't be the last (in general... no specific
plans here). =(