GNU bug report logs - #15992
'ls' ignores term capabilities when generating color.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15992 in the body.
You can then email your comments to 15992 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: 'ls' ignores term capabilities when generating color.
Date: Thu, 28 Nov 2013 12:31:06 -0800

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?

;-)

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: bug-coreutils <at> gnu.org
Cc: Linda Walsh <coreutils <at> tlinx.org>, 15992 <at> debbugs.gnu.org
Subject: Re: bug#15992: 'ls' ignores term capabilities when generating color.
Date: Thu, 28 Nov 2013 16:35:32 -0500

[Message part 1 (text/plain, inline)]

On Thursday 28 November 2013 15:31:06 Linda Walsh wrote:
> While I do have an alias that says:
> alias ls='ls -CF --show-control-chars --color=always'

there's your problem.  don't use --color=always.
-mike

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 15992 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 15992 <at> debbugs.gnu.org
Subject: Re: bug#15992: 'ls' ignores term capabilities when generating color.
Date: Fri, 29 Nov 2013 01:36:21 +0000

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

Message #17 received at 15992 <at> debbugs.gnu.org (full text, mbox):

From: Guilherme de Almeida Suckevicz <guito.linux <at> gmail.com>
To: 15992 <at> debbugs.gnu.org
Subject: Re: bug#15992: 'ls' ignores term capabilities when generating color.
Date: Wed, 16 Apr 2014 10:51:00 -0300

[Message part 1 (text/plain, inline)]

Hi Pádraig,

I made a patch for this issue according to the tips above.
I hope that is ok!

[guilherme <at> almeida build]$ diff ../src/ls.c ../src/ls-orig.c
111d110
< #include "dircolors.h"
2330,2360d2328
<
< /* GCC warning about pure attribute. */
< bool check_term_type (const char *) __attribute__ ((pure));
<
< /* Check if the content of TERM is a valid name in dirname.h . */
< bool
< know_term_type (void)
< {
<   char const *line;
<   const char *term;
<
<   term = getenv ("TERM");
<   if (! term || ! *term)
<     return false;
<
<   line = G_line;
<   while (line - G_line < sizeof (G_line))
<     {
<       /* Get just lines begining with 'TERM '. */
<       if (STRNCMP_LIT (line, "TERM ") == 0)
<     {
<       if (STREQ (term, line + 5))
<         return true;
<     }
<
<       line += strlen (line) + 1;
<     }
<
<   return false;
< }
<
2370d2337
<
2372,2382c2339
<     {
<       /* If COLORTERM is not set, check if the term type is know. */
<       if (getenv ("COLORTERM") == NULL)
<     {
<       if (! know_term_type ())
<         {
<           print_with_color = false;
<           return;
<         }
<     }
<     }
---
>     return;



Thank you very much for help me! :D
Guilherme Almeida.

[Message part 2 (text/html, inline)]

Message #20 received at 15992 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Guilherme de Almeida Suckevicz <guito.linux <at> gmail.com>
Cc: 15992 <at> debbugs.gnu.org
Subject: Re: bug#15992: 'ls' ignores term capabilities when generating color.
Date: Wed, 16 Apr 2014 16:56:04 +0100

[Message part 1 (text/plain, inline)]

On 04/16/2014 02:51 PM, Guilherme de Almeida Suckevicz wrote:
> Hi Pádraig,
> 
> I made a patch for this issue according to the tips above.
> I hope that is ok!
> 
> [guilherme <at> almeida build]$ diff ../src/ls.c ../src/ls-orig.c

Note the patch is reversed, also we prefer unified format,
also we'd much prefer a patch against the git repo.
For general notes on supplying patches see:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=README-hacking;hb=HEAD

> 2372,2382c2339
> <     {
> <       /* If COLORTERM is not set, check if the term type is know. */
> <       if (getenv ("COLORTERM") == NULL)
> <     {
> <       if (! know_term_type ())
> <         {
> <           print_with_color = false;
> <           return;
> <         }
> <     }

          you want a return here too

> <     }

I've cleaned up the patch and added a test.
If you're Ok with it I'll push.

thanks,
Pádraig.

[ls-dumb-term.patch (text/x-patch, attachment)]

Message #23 received at 15992 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Guilherme de Almeida Suckevicz <guito.linux <at> gmail.com>
Cc: 15992 <at> debbugs.gnu.org
Subject: Re: bug#15992: 'ls' ignores term capabilities when generating color.
Date: Wed, 16 Apr 2014 20:21:27 +0200

On 04/16/2014 05:56 PM, Pádraig Brady wrote:
> I've cleaned up the patch and added a test.
> If you're Ok with it I'll push.

Minor nit:

> +++ b/tests/ls/color-term.sh
> [...]
> +# Don#t output colors

s/Don#t/Don't/

Otherwise +1.

Thanks & have a nice day,
Berny

Message #28 received at 15992-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Guilherme de Almeida Suckevicz <guito.linux <at> gmail.com>,
 15992-done <at> debbugs.gnu.org
Subject: Re: bug#15992: 'ls' ignores term capabilities when generating color.
Date: Thu, 17 Apr 2014 02:14:28 +0100

On 04/16/2014 07:21 PM, Bernhard Voelker wrote:
> On 04/16/2014 05:56 PM, Pádraig Brady wrote:
>> I've cleaned up the patch and added a test.
>> If you're Ok with it I'll push.
> 
> Minor nit:
> 
>> +++ b/tests/ls/color-term.sh
>> [...]
>> +# Don#t output colors
> 
> s/Don#t/Don't/
> 
> Otherwise +1.
> 
> Thanks & have a nice day,
> Berny
> 
Guilherme confirmed privately that adjustments are OK,
so pushing now.

thanks for the review,
Pádraig.

Message #31 received at 15992 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 15992 <at> debbugs.gnu.org, coreutils <at> tlinx.org
Subject: Re: bug#15992: 'ls' ignores term capabilities when generating color.
Date: Fri, 18 Apr 2014 11:28:16 +0100

[Message part 1 (text/plain, inline)]

On 04/17/2014 02:14 AM, Pádraig Brady wrote:
> On 04/16/2014 07:21 PM, Bernhard Voelker wrote:
>> On 04/16/2014 05:56 PM, Pádraig Brady wrote:
>>> I've cleaned up the patch and added a test.
>>> If you're Ok with it I'll push.
>>
>> Minor nit:
>>
>>> +++ b/tests/ls/color-term.sh
>>> [...]
>>> +# Don#t output colors
>>
>> s/Don#t/Don't/
>>
>> Otherwise +1.
>>
>> Thanks & have a nice day,
>> Berny
>>
> Guilherme confirmed privately that adjustments are OK,
> so pushing now.

I pushed this follow up to avoid test failures
(since tests were dependent on the COLORTERM
being set in the environment).

thanks,
Pádraig.

[ls-colorterm.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.