Open melak47 opened 7 years ago
I was trying to achieve color output with gcc using ninja / ccache and wasn't successful either. Maybe related?
@Ede123 The linked patch specifically detects mintty named pipes, and wouldn't recognize ninja's named pipes ( "\\.\pipe\ninja_pid<PID>_sp<IOPORT>"
) as a "terminal" to enable color support for, so you'd have to use -fdiagnostics-color(=always)
.
Even then, ninja will strip such escape codes unconditionally under certain conditions (see StripAnsiEscapeCodes
used in build.cc).
So it should work when the output goes to a real console window (regular conhost, ConEmu, winpty). If ninja's output is going to a pipe, or you use verbose output, the escape codes will be stripped, though.
I tried -fdiagnostics-color
, but couldn't make it work with that option alone. I must admit it also wasn't important enough for me to investigate further, since there were three programs involved (ninja, ccache and g++) each of which could have stripped the coloring...
The color support currently implemented (in this patch) doesn't always work outside of bash/mintty/winpty etcetera.
In gcc/diagnostic-color.c with the above patch:
should_colorize
is not called if you're using-fdiagnostics-color=always
, so VT processing is never actually enabled. Powershell has it on by default, so it works by accident, but cmd does not.should_colorize
is called,w_isatty
is never called if the env varTERM
doesn't exist (which is rarely the case in a plain cmd or powershell session) or equals "dumb", so VT processing is still not enabled.You can of course set
TERM
to some bogus value like "cmd", but your remote shells may not appreciate that - and "xterm" or even "ansi" can lead to somewhat garbled output on your end of a SSH connection. Maybe "cygwin" could work, but I'd prefer not to have to work around this in the first place.