svn commit: r337956 - in head: . bin/ls

[Kyle Evans]

On Sat, Aug 18, 2018 at 12:35 AM, Rodney W. Grimes
<freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>> > On Fri, Aug 17, 2018 at 10:26 AM, Kyle Evans <kevans at freebsd.org> wrote:
>> > > On Fri, Aug 17, 2018 at 10:24 AM, Rodney W. Grimes
>> > > <freebsd at 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 at x230a:~ # gls --color=none
> 828phone.tgz  Desktop  Downloads  firefox.core  soffice.bin.core
> root at x230a:~ # gls --color=never
> 828phone.tgz  Desktop  Downloads  firefox.core  soffice.bin.core
> root at 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