autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#6427: Autotest: enable colored test results.


From: Pádraig Brady
Subject: Re: bug#6427: Autotest: enable colored test results.
Date: Tue, 15 Jun 2010 10:50:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]