The ebuild command always shows color, ignoring NOCOLOR in /etc/make.conf Attached is a patch to fix this; not sure if this is the best way to go about it.
Created attachment 48980 [details, diff] ebuild.patch
Created attachment 48992 [details, diff] output.patch I think output.py should always strip color when (not sys.stdout.isatty()) (this patch fixes that) Most programs that import output.py usually do this anyways and should be the default behaviour. This would be a fix for most complaints about NOCOLOR because its usually people using ebuild/emerge/repoman etc. from within an ide like vim, abeni etc. (i.e. bug# 77566)
Created attachment 58847 [details] i think the location of this processing should be in output.py this patch forces pym/output.py to nocolor() if sys.argv contains --nocolor or the terminal is not capable of displaying color. perhaps the right way to do this is to have the argument processing defer to a function in output.py to take care of the --nocolor option instead of the end-run around the normal argument procesing that i've done.
When is this actually useful? What color output is there from portage?
ebuild CPV.ebuild digest will generate color and can be bad on terminals that don't support color ( craptastic telnet terminals fex ). While I don't think it's a critical issue; just some junk in the terminal, the fix is quite trivial.
This is in svn r2773 for release in 2.1_pre6. (In reply to comment #3) > i think the location of this processing should be in output.py I'd rather keep a UI decision like this in bin/ebuild because I don't like the idea of the global sys.stdout.isatty() and NOCOLOR environment variable automatically affecting the output module internals.
Released in 2.1_pre6.
