bug#15992: 'ls' ignores term capabilities when generating color.

[Pádraig Brady]

On 11/28/2013 08:31 PM, Linda Walsh wrote:
> I logged in on a *dumb* terminal
> and did an 'ls'.  Rather than a file list, I got:
> 
> \x1b[00;32mwpad.dat\x1b[0m*
> \x1b[00mwpad_socks.dat\x1b[0m
> \x1b[00mwuredir.xml\x1b[0m
> \x1b[00mx.c\x1b[0m
> \x1b[00mx.c.orig\x1b[0m
> \x1b[00;32mx1\x1b[0m*
> \x1b[00mxaml\x1b[0m
> \x1b[01;35mxmision-web\x1b[0m/
> \x1b[01;35mxrdp\x1b[0m/
> \x1b[00mxrdp-sesadmin.log\x1b[0m
> \x1b[00;32mxtree117.zip\x1b[0m*
> \x1b[00;32mxtree2b-20050606.zip\x1b[0m*
> \x1b[01;35mxx\x1b[0m/
> \x1b[01;35mxxx\x1b[0m/
> \x1b[00;32myast2.txt\x1b[0m*
> \x1b[40;33;01mzero\x1b[0m
> \x1b[01;35mzips\x1b[0m/
> \x1b[01;35mztars\x1b[0m/
> \x1b[01;35mztest\x1b[0m/
> \x1b[00mzyppinst\x1b[0m
> ------------------
> 
> While I do have an alias that says:
> alias ls='ls -CF --show-control-chars --color=always'
> 
> If the terminal HAS NO color capabilities, I would expect
> it not to display anything where color was selected,
> as the mapping for switching colors on a dumb terminal
> is "".
> 
> I tried settings for "TERM":
> of "none", "dumb", and "" (empty)
> 
> All gave the same strings as would be correct
> for a 16-color terminal.
> 
> IMO, "ls" shouldn't print out "bogus" strings for color
> that are not in the listed "TERM"inal's capabilties.
> 
> Wouldn't that be the wisest course of action?  Or is
> there a requirement, "poSomewhereIx" to print garbage strings
> to terminals that don't have specific capabilities?
> 
> ;-)

So this is a fair point.

I see the --color option as controlling color output based
on whether output is a terminal or not.  It would be beneficial
to have more control to disable coloring if output is a terminal,
but can't parse the color codes.

Note that color handling for ls is split into dircolors to generate
the static list of color values to use. ls itself doesn't query the $TERM.

Now dircolors also works off a static list which it converts to the
LS_COLORS env variable if it finds that the current $TERM is tagged
in its config. So if dircolors doesn't find a matching $TERM
it will output an empty LS_COLORS env variable. So far so good.

However ls will default to its builtin ansi color config
with a missing or empty LS_COLORS.  It is debatable as
to whether an empty LS_COLORS should disable colors completely,
but I noticed that an invalid LS_COLORS will disable coloring,
and output a warning. I.E. the following will not colorize the output:

  LS_COLORS='blah' ls --color=always

That's at least inconsistent with an empty LS_COLORS not changing anything.
So what we could do to in ls to address this is:

if $LS_COLORS is unset or empty
  // dircolors not run or is having issues with this terminal
  if ($COLORTERM is set) or ($TERM = any in dircolors.h)
    # go with internal set
  else
    # disable coloring

In that way the $TERM would be honored, but could
be overridden with LS_COLORS.

thanks,
Pádraig.

p.s. dircolors might honor $COLORTERM too,
so that every $TERM in existence doesn't need to be added,
though COLORTERM is not passed to remote ssh sessions
like the TERM variable is for example.

p.p.s a separate point that came to mind is that
dircolors might support being passed a directory
containing color configs to parse, which it continues
doing until it finds one with a matching $TERM