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

[Kyle Evans]

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.

>>
>> 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.

>
>> 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. =) I'm
certainly not averse to adding a --color long option, and will do so
when I find the time (later today, most likely).

Thanks,

Kyle Evans