> Date: Sat, 24 Dec 2011 13:46:28 -0800 > From: Paul Eggert <[email protected]> > CC: [email protected] > > How about something like this instead? > > #include "colorize.h" > > Where colorize.h looks like this: > > #define PR_SGR_START(s) PR_SGR_FMT( SGR_START, (s)) > #define PR_SGR_END(s) PR_SGR_FMT( SGR_END, (s)) > #define PR_SGR_START_IF(s) PR_SGR_FMT_IF(SGR_START, (s)) > #define PR_SGR_END_IF(s) PR_SGR_FMT_IF(SGR_END, (s)) > static int > should_colorize (int fd) > { > char const *t; > return isatty (fd) && (t = getenv ("TERM")) && !STREQ (t, "dumb"); > } > > And there's a new file ms/colorize.h that contains > something like this: > > void PR_SGR_START (char const *); > void PR_SGR_END (char const *); > void PR_SGR_START_IF (char const *); > void PR_SGR_END_IF (char const *); > int should_colorize (int); > > and a new file ms/colorize.c that contains implementations of the > above. This is just a sketch; the exact interface could no doubt be > improved. > > This way, the static var could be in ms/colorize.c, and the > Microsoft-specific code could all be in the ms subdirectory. When > compiling on Windows, we prepend -Ims so that its colorize.h is > included.
Granted, I thought about something like this as well, but didn't have neither time nor auto-tools related expertise to make changes in the structure of the package. It's a pity the color stuff was not on a separate file to begin with (since it's inherently non-portable anyway). However, if someone produces a patch, I can test it. Btw, the definition of should_colorize you show above is correct only for Posix hosts; DOS and Windows hosts need a slightly different one, as $TERM is normally not set there. Thanks.
