On Sat, May 13, 2017 at 7:50 PM, Miroslav Rovis <miro.ro...@croatiafidelis.hr> wrote: > On 170513-12:53-0500, R0b0t1 wrote: >> On Sat, May 13, 2017 at 9:25 AM, Miroslav Rovis >> <miro.ro...@croatiafidelis.hr> wrote: >> > On 170510-20:03-0400, Walter Dnes wrote: >> >> On Wed, May 10, 2017 at 01:35:24PM -0500, R0b0t1 wrote >> >> >> >> > The option is "-fdiagnostics-color=never" or "-fno-diagnostics-color". >> >> > You can also set the environment variable GCC_COLORS to the empty >> >> > string. The latter is probably more useful in the context of portage. >> >> >> >> Thank you. I successfully tried... >> >> >> >> GCC_COLORS="" emerge icewm >> > Another tip to remember. >> > >> >> I suppose the next step is to add GCC_COLORS="" to make.conf. >> >> >> > I wonder why sticking " --color=n" in the EMERGE_DEFAULT_OPTS in >> > make.conf (e.g. mine is: >> > >> > EMERGE_DEFAULT_OPTS="--keep-going --with-bdeps=y --autounmask-keep-masks >> > --ask --verbose --color=n" >> > >> > does only partly its job. Erratically, I'd say. You never know if it >> > will or not remove color... A bug should be posted for that, but I have >> > a partly broken system at this time... >> > >> >> That switch only handles the coloring of portage output. I suggested >> using GCC_COLORS precisely because "--color=n" doesn't seem to >> propagate to subcommands which do output coloring. >> >> Another program you might want to disable output coloring for is >> CMake, using CMAKE_COLOR_MAKEFILE=OFF. >> > > Thanks for the tip! But let me see... Like the above (repasting): >> >> GCC_COLORS="" emerge icewm > pr maybe stick in the /etc/portage/bashrc or in some other way? >
As Walter suggested make.conf seems the ideal place. Should that fail I'm not entirely sure, as I believe portage does some pretty heavy environment sandboxing.
