Warren Young <war...@etr-usa.com> writes: > On Oct 25, 2017, at 8:56 AM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> > wrote: >> >>> It's also crazy that "--color-tests=y" or "--color-tests=1" won't work >> >> While I like color in photos and nature, automatic colorization of >> output often causes problems for me since it often renders the text >> unreadable. > > Why, exactly? > > I ask because the default color scheme of some terminal emulators > makes the dark blue on black text difficult for me to read, but that’s > easily fixed by switching the color scheme. > >> It also introduces terminal escape codes into the text output, which can >> cause issues if captured output is later displayed on something other than a >> ANSI terminal. > > Both problems are caused by programs that hard-code literal ANSI/VT > codes into text output. While ANSI-family terminal protocols have > taken over the world now, that’s still a bad practice which needs to > be smacked down wherever it reappears. > > Well-behaved programs (e.g. GNU ls --color=auto, colordiff…) suppress > color output when stdout is not a terminal. They do that by making > calls like isatty(3) if written in C or test(1) -t if written in > shell. > > 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.
Colors are already automatically used when possible [1] and can be disabled with the AM_COLOR_TESTS environment variable. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 [1] https://www.gnu.org/software/automake/manual/automake.html#Simple-tests-and-color_002dtests