automake
[Top][All Lists]
Advanced

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

Re: automake: tap-driver.sh: cleanup and revival.


From: Russ Allbery
Subject: Re: automake: tap-driver.sh: cleanup and revival.
Date: Wed, 25 Oct 2017 17:03:34 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Warren Young <address@hidden> writes:

> As for the portability of ANSI terminal escape codes, it’s still best to
> delegate such things to curses or libraries like it, despite the near
> ubiquity of ANSI-family terminal emulators.

Does anyone really use a non-ANSI terminal to run Automake test suites?  I
haven't seen one in probably twenty years.  I'm sure they still exist in
odd corners of some data center, but I'm quite dubious they would be
running Automake-driven test suites, as opposed to being connected to some
ancient mainframe that's as obscure as the terminal.

I think this is pointless portability akin to testing whether the C
library supports memcpy.  I suppose in theory one could use tput to get
the appropriate strings, but now you're trading a theoretical portability
issue (a terminal type that's so esoteric as to not support basic ANSI
escape codes) for a very real and practical portability issue (a system
that doesn't have the curses/ncurses binaries installed).  This doesn't
seem like a benefit.

(I'm in favor of disabling color by default, though, and having the
default color enabled mode test whether stdout is a tty before adding
colors.  Those address the much more common case of redirecting test
output to a file, where the ANSI codes cause a lot of problems.)

-- 
Russ Allbery (address@hidden)              <http://www.eyrie.org/~eagle/>



reply via email to

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