[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [PATCH] ls: recognize "never" for LS_COLORS
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2021-11-09 14:00:55
Message-ID: CAK1hOcOBWsk93XEgPEGja53OG7t=x9qig2L6Lu7hvtQg-TKvog () mail ! gmail ! com
[Download RAW message or body]

On Thu, Oct 21, 2021 at 1:40 PM roger peppe <rogpeppe@gmail.com> wrote:
> This patch was made to commit 836b79211df3aeaba1b8b65c6db5ee6193172cc0.
> 
> The standard `ls` command uses the value "never" (not "none") to signify that the \
> output should not be colorized. This change lets the same value apply consistently \
> to `busybox ls` too.

Er... no it does not?

I ran a few experiments and it seems there is no value of LS_COLORS
environment variable which simply switches off coloring.
Well, "none" and "never" do switch it off, but only because any
invalid value does it:

$ LS_COLORS=none ls -l --color
ls: unparsable value for LS_COLORS environment variable
<shows uncolored output>

$ LS_COLORS=never ls -l --color
ls: unparsable value for LS_COLORS environment variable
<shows uncolored output>

Even "always" does it too:

$ LS_COLORS=always ls -l --color
ls: unparsable value for LS_COLORS environment variable
<shows uncolored output>

Empty value is not switching coloring off.

So, our behavior is not matching coreutils
(we accept LS_COLORS=none), and your patch does not
improve that.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]