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
