On 14/06/10 21:23, Eric Blake wrote:
>>> Personally, I like tri-state color options: --color=no or --color=never
>>> to disable, --color=yes or --color=always to enable, and --color=auto or
>>> the simpler --color to depend on tty status. Are you making 'yes' a
>>> synonym for 'always' or for 'auto'? Should we support other common
>>> synonyms?
>>
>> I meant yes=auto. I realize this is different from how ls does it, and
>> I'm fine with doing it another way.
>
> My quick testing shows that when directed to a tty, both ls and grep
> treat all four of '--color', '--color=auto', '--color=yes', and
> '--color=always' as a command to turn on color. More interesting is
> collecting the output:
>
> ls --color => color
> ls --color=yes => color
> ls --color=auto => plain
> ls --color=always => color
> grep --color => plain
> grep --color=yes => color
> grep --color=auto => plain
> grep --color=always => color
>
> That is, ls --color implies ls --color=always, while grep --color
> implies grep --color=always.
grep --color=auto you mean.
> It's probably worth a bug report to coreutils (cc'd), since I prefer the
> grep behavior. Should we also raise a bug against the GNU Coding
> Standards to codify a preferred variant?
Yes I prefer the grep behavior, but I'm not sure we can
change ls at this stage?
>> I'm also fine with 'never' and
>> 'auto' as additional synonyms. However, I very much think that if some
>> option --foo[=ARG] accepts no and yes and other arguments, then yes
>> --foo should be a synonym for --foo=yes, not anything else.
>
> So you are arguing yet a third behavior from either coreutils or grep,
> which is that --color implies --color=yes, but that yes is an alias for
> 'auto' rather than 'always'. I could see your behavior making sense as
> well. But again, it argues for standardization among GNU projects.
ls has these synonyms:
"always", "yes", "force",
"never", "no", "none",
"auto", "tty", "if-tty", NULL
We only document the first column which is a good thing.
> Any other examples we can look at, to see if there is already a majority
> in behavior?
>
>>> I don't know how to easily detect ascii vs. ebcdic ESC (which is a
>>> different encoding); \e and \E escapes are common, but non-portable.
>>
>> Is there any chance that an EBCDIC system accepts ANSI terminal color
>> escape sequences? If not, then what would be the equivalent there?
>> Am I confusing different entities here?
>
> I have no idea of anyone that uses an EBCDIC system that also uses
> terminal escape sequences. Let's just go with hard-coding ASCII and
> wait for the bug reports (after all, we DID get some bug reports, along
> with a patch, about one use of m4_translit in 2.65, which have already
> been applied to make autoconf.git more EBCDIC-friendly).
I've wondered about how general the color codes we use are.
Using termcap/terminfo would be most general but since
we've had no reports about it yet I think we should stick
with the simple hardcoded scheme.
I.E. the following currently outputs colors:
TERM=dumb ls --color=auto
The l¹ script I use to wrap `ls` works around
this "limitation" by essentially doing:
if ! tput setaf 1 >/dev/null 2>&1 && ! tput AF 1 >/dev/null 2>&1; then
color_when=never
else
color_when=auto
fi
ls --color=$color_when
cheers,
Pádraig.
¹ http://www.pixelbeat.org/scripts/l
