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.