GCC 4.9 has support for colored output with -fdiagnostics-color. When it's used the build logs end up looking like this: ^[[01m^[[Kbzip2.c:^[[m^[[K In function '^[[01m^[[KtestStream^[[m^[[K': ^[[01m^[[Kbzip2.c:612:35:^[[m^[[K ^[[01;33m^[[Kwarning: ^[[m^[[Kvariable '^[[01m^[[Knread^[[m^[[K' set but not used [-Wunused-but-set-variable] Int32 bzerr, bzerr_dummy, ret, nread, streamNo, i; ^[[01;32m^[[K ^^[[m^[[K Not only is it unreadable but it makes the caret pointer useless. bzip2.c: In function 'testStream': bzip2.c:612:35: warning: variable 'nread' set but not used [-Wunused-but-set-variable] Int32 bzerr, bzerr_dummy, ret, nread, streamNo, i; ^ Is there any way to avoid recording these codes?
1. gcc-4.9 is not in portage, therefore unsupported. ;) 2. CFLAGS+=-fno-diagnostics-color?
How is that helpful when the log is already attached to a bug report?
well, logs have always been like that ... the builtin funcs like einfo and such emit escape sequences. if you use `less`, it renders correctly. it is a bit annoying that when you pop open an editor, the sequences are in there, but i prefer having the colors after the fact (for use in `less`).
Right, and I bet it applies to clang and cmake too. I just didn't notice until now. I can try getting used to using less instead.
(In reply to Ryan Hill from comment #4) > Right, and I bet it applies to clang and cmake too. I just didn't notice > until now. I can try getting used to using less instead. I don't know about clang, but AFAIK CMake only writes ANSI colors if the output is a terminal. That said, I think this issue (if it is regarded as such by you) is best reported to upstream GCC. Another issue is emerge itself, which unconditionally writes ANSI colors. IMHO, changing this behavior would greatly increase the readability of attached bug reports here in bugzilla.
(In reply to Tolga Dalman from comment #5) having a bugzilla module that'd render the log with color sequences would be even better
(In reply to Tolga Dalman from comment #5) > I don't know about clang, but AFAIK CMake only writes ANSI colors if the > output is a terminal. That said, I think this issue (if it is regarded as > such by you) is best reported to upstream GCC. Nothing's wrong upstream. We're teeing screen output to a log (or however it gets done under the hood), escape sequences and all.
It's not just external software that does this. Portage itself puts escape chars in logs. See bug 511412.
*** Bug 511412 has been marked as a duplicate of this bug. ***
