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

[Rodney W. Grimes]

[ 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?

> 
> ls(1) on FreeBSD historically honors -an- environment variable for
> enabling color.

Short history, long history it had no color support at all.

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

-- 
Rod Grimes                                                 rgrimes at freebsd.org