Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Aug 2018 07:13:35 -0500
From:      Kyle Evans <kevans@freebsd.org>
To:        "Rodney W. Grimes" <rgrimes@freebsd.org>
Cc:        src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r337956 - in head: . bin/ls
Message-ID:  <CACNAnaFPhiPoN6B-vMWSerpx8FV55NkV779EnKVbWpSZitkd5A@mail.gmail.com>
In-Reply-To: <201808180535.w7I5ZfsS062952@pdx.rh.CN85.dnsmgr.net>
References:  <201808171549.w7HFndsp059932@pdx.rh.CN85.dnsmgr.net> <201808180535.w7I5ZfsS062952@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 18, 2018 at 12:35 AM, Rodney W. Grimes
<freebsd@pdx.rh.cn85.dnsmgr.net> wrote:
>> > On Fri, Aug 17, 2018 at 10:26 AM, Kyle Evans <kevans@freebsd.org> wrote:
>> > > On Fri, Aug 17, 2018 at 10:24 AM, Rodney W. Grimes
>> > > <freebsd@pdx.rh.cn85.dnsmgr.net> wrote:
>> > >>> Author: kevans
>> > >>> Date: Fri Aug 17 04:15:51 2018
>> > >>> New Revision: 337956
>> > >>> URL: https://svnweb.freebsd.org/changeset/base/337956
>> > >>>
>> > >>> Log:
>> > >>>   ls(1): Add --color=when
>> > >>>
>> > >>>   --color may be set to one of: 'auto', 'always', and 'never'.
>> > >>>
>> > >>>   'auto' is the default behavior- output colors only if -G or COLORTERM are
>> > >>
>> > >> Why different than coreutils ls?   Default for coreutils is none.
>> > >
>> > > I guess this was worded poorly and you skipped both the review and
>> > > reading the diff... this is still contingent on environment variables
>> > > or -G being specified.
>> > >
>> > >>>   set, and only if stdout is a tty.
>> > >>>
>> > >>>   'always' is a new behavior- output colors always. termcap(5) will be
>> > >>>   consulted unless TERM is unset or not a recognized terminal, in which case
>> > >>>   ls(1) will fall back to explicitly outputting ANSI escape sequences.
>> > >>>
>> > >>>   'never' to turn off any environment variable and -G usage.
>> > >> Why different than core utils?  Coreutils uses none.
>> > >
>> > > I guess this was worded poorly and you skipped both the review and
>> > > reading the diff... this is still contingent on environment variables
>> > > or -G being specified.
>> > >
>> >
>> > ... copy-paste-o. The version of coreutils ls(1) that I have uses
>> > 'never' for this. There is no valid 'none' value.
>>
>> Oh boy, we need to investiage that then, cause it seems
>> as if the official page says none.   Does your say it
>> has a different default value too?
>
> And our package of gnu coreutils also says never, so ignore my
> raising the issue of none vs never, that needs to be raised
> with the gnu folks as it seems as if there online manual and
> the code is in conflict.  Ooopss.. retract that here we go...
> I have our pkg coreutils installed:

This is what I was afraid of. =(

> root@x230a:~ # gls --color=none
> 828phone.tgz  Desktop  Downloads  firefox.core  soffice.bin.core
> root@x230a:~ # gls --color=never
> 828phone.tgz  Desktop  Downloads  firefox.core  soffice.bin.core
> root@x230a:~ # gls --color=theychangedit
> gls: invalid argument 'theychangedit' for '--color'
> Valid arguments are:
>   - 'always', 'yes', 'force'
>   - 'never', 'no', 'none'
>   - 'auto', 'tty', 'if-tty'
> Try 'gls --help' for more information.

Except that's even worse than I thought... I assumed it was "always";
"never", "none"; "auto" having kept both "never" and "none" for
backwards compat. =\

> So it looks as if we need to add a we bit
> more to make our use of --color match what
> coreutils actually allows.
>
> *Runs and ducks* cause Kyle has already gone way above
> the call of duty on this one!

More than happy to add all of these aliases so that we do the right
thing if the user is explicit. =) I generally just don't want to
change the default behavior away from respecting the environment/-G
since we've done this for so long now. I believe in compatibility with
GNU tools so that user doesn't get surprised when an option they want
doesn't exist (see: the various long options commits I've made in the
past), but I believe a lot less in bending how we do things by default
to match when we already have our own precedent set.

Thanks,

Kyle Evans



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaFPhiPoN6B-vMWSerpx8FV55NkV779EnKVbWpSZitkd5A>