[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Autotest: enable colored test results.
Re: Autotest: enable colored test results.
Mon, 14 Jun 2010 14:23:51 -0600
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre Mnenhy/0.8.2 Thunderbird/3.0.4
[the coreutils portion of this email starts half-way down]
On 06/14/2010 01:45 PM, Ralf Wildenhues wrote:
> Hi Eric,
> quoting your reply out of order:
> * Eric Blake wrote on Mon, Jun 14, 2010 at 07:22:31PM CEST:
>> On 06/13/2010 12:50 AM, Ralf Wildenhues wrote:
>>> The logical next step for Autotest to be on par with Automake's
>>> Unlike Automake, the testsuite author does not have to do anything for
>>> the user to be able to use color; AT_COLOR_TESTS only changes the
>>> default to yes. We could easily let it accept an optional argument, if
>>> you think it is useful.
>> I'm debating whether:
> This currently does not work:
>> Did you make sure that AT_COLOR_TESTS can be specified either side of
>> AT_INIT, or is there a fixed invocation order that authors must be aware of?
> Right now it has to be specified before AT_INIT. If there's a diversion
> thinhy we can easily fix that with, great, otherwise I guess it would
> need documentation and order warning in the code. Help?
It seems like it would merely be a matter of unconditionally emitting
at_color=no in an early diversion, and having AT_COLOR_TESTS emit
at_color=auto in an intermediate diversion, all before the option
parsing that appears in a later diversion. That way, if the user didn't
specify --color, they pick up the appropriate default.
That also implies that anything else that checks at m4-time whether
AT_color is defined (such as your m4_ifdef for changing the --help
output text) must be m4_wrap'd to delay any output based on that
decision of AT_color until after the user's source file has been
completely read in. Then again, we already m4_wrap some of our --help
text in order to accurately tell the user how many AT_SETUPs we
encountered, so this may already be taken care of given the current
architecture of autotest.
I'll see if I can get some time to help you figure that out, if that
wasn't enough of a hint.
>> 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
> 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.
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?
> 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.
Any other examples we can look at, to see if there is already a majority
>> 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).
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Description: OpenPGP digital signature