automake-patches
[Top][All Lists]
Advanced

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

Re: colorful tests


From: Ralf Wildenhues
Subject: Re: colorful tests
Date: Sat, 10 Nov 2007 10:53:55 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Bob,

* Bob Proulx wrote on Fri, Nov 09, 2007 at 12:36:12AM CET:
> Ralf Wildenhues wrote:
> > - with TERM=vt100, on my GNU/Linux system there are still colors
> >   generated by tput, so I did not use that TERM setting,
> 
> That is discouraging.  The vt100 does not support color and tput
> should not produce escape sequences for it.  I believe that would
> indicate a bug in the vt100 terminfo on the systems you tested.  The
> 'tput' command (correctly) does not produce color output with
> TERM=vt100 on my Debian GNU/linux system (nor on HP-UX) so I assume
> these are on other systems.  If you are motivated then a bug report to
> those systems would be probably be in order so that they can be
> improved.  I am surprised that at this point in history that a vt100
> terminal database entry wouldn't be correct!  Oh well.

Hmm.  Upon retesting, I can't reproduce this.  Sorry for that glitch.

> > - On virtually no other system that I have access to does color output
> >   work as expected using tput.  At least on some they do, when I keep
> >   the TERM setting given by my terminal (xterm), but that does not help
> >   the tests.
> 
> I am sorry but I am having trouble parsing that sentence.  On no other
> system does it work?  Or on no other system does it _not_ work?  (HP-UX
> is my other traditional system and it handles tput as expected.)

Using tput worked on very few systems only.  Basically, it worked on
GNU/Linux and Solaris 10 (but not earlier).

> > - However, ANSI sequences seem to work everywhere I tested.  Disclaimer:
> >   I only tested with an xterm over a ssh session and inside a screen
> >   session.  But I did test OpenBSD, FreeBSD, Solaris, AIX, Tru64.
> 
> And on HP-UX too.

Good.

> > - go back to using ANSI escape sequences,
> 
> I think that means only worry about the TERM=ansi case for the purpose
> of testing.  I think that is fine.

That's basically what I did now in the test, except the escape sequences
don't need TERM=ansi to work.

> > - new test.  If `expect' is present, it is used to simulate a terminal
> >   near the end of the test.  Otherwise, the test returns SKIP if all
> >   other test commands before that succeeded.
> 
> Okay.  Since expect is optional I think that will be fine.  I would
> hate to make that a hard requirement.

Yes, definitely.  I never intended to make it compulsory.

> In that eventuality I would
> suggest looking for either expect or script since script can be used
> to perform this type of test too.  Classic Unix systems are probably
> much more likely to have script available by default than expect.

Oh, hmm.  OpenBSD and Solaris script know
     script [-a] [file]

and don't eat commands piped from stdin,
FreeBSD accepts commands from stdin or the arguments:
     script [-akq] [-t time] [file [command ...]]

and the one on Debian has another different syntax:
     script [-a] [-c COMMAND] [-f] [-q] [-t] [file]

Besides, for this part of the test, it is not so much of a problem if
it's not executed on all systems (that "test -t" works as expected is
not much doubted), it's more to ensure Automake won't change its
behavior accidentally in the future.

> > - macro AM_COLOR_TESTS as lever for the user in both directions:
> >   turn color off even when it would be displayed, and force color on
> >   even when not on a terminal.  This is both nice for users of `less -R'
> >   and for actually testing colored output inside a script.
> 
> Thank you very much for this!  It is just what is needed.  It makes me
> quite happy to have a control for this.

You're certainly welcome, control over the output is important for me,
too, so I basically just scratched an itch of mine there.

Cheers,
Ralf




reply via email to

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