I have many times wanted to be able to do a: "emerge --force-color -vpuDN world | less -r" It's possible with attached "patch" /Claes
Created attachment 93237 [details] The "patch" is against sys-apps/portage-2.1-r1
Created attachment 93238 [details, diff] Not gzipped this time ;-)
In 2.1.1_pre it's currently possible to force color by exporting NOCOLOR=no in the environment. *** This bug has been marked as a duplicate of 42115 *** *** This bug has been marked as a duplicate of 42115 ***
I think its easier and more logical to do: emerge --force-color ... | less -r than: NOCOLOR=no emerge ... | less -r
Indeed, but we'd really like to condense it into --color=yes,no,auto so that we don't need separate --force-color, --auto-color, and --no-color options.
(In reply to comment #5) > Indeed, but we'd really like to condense it into --color=yes,no,auto so that we > don't need separate --force-color, --auto-color, and --no-color options. > Is --color=auto going to be able to knew that "| less -r" is able to display "colors"?
Forget it! I'm to tired to argue.... I have to get some sleep now! *** This bug has been marked as a duplicate of 42115 ***
How would it know? I'd assume that auto would be just like the current default behavior, which is to disable color when sys.stdout.isatty() returns False.
hi, i think a cmdline option has some advantages over a environment variable. but call it --color=<state> instead of --<state>color(eg --force-color) is better, yes. i want to point out that: 1)if some apps really read the emerge output and NOCOLOR=no is set, they get into trouble 2)emeber, you can easily add "alias emerge='emerge -color=yes'" to your rc's instead of setting NOCOLOR and this or this way, you have color through pipes enabled with just typing emerge. BUT with the cmdline option it's not possible that the apps get colored data. if the apps invoke emerge via its full path, they don't use the alias set. but they always use the environment variable...
