Summary: | sys-apps/sandbox: respect color settings from portage | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Martin Walch <walch.martin> |
Component: | Core - Interface (emerge) | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED WORKSFORME | ||
Severity: | enhancement | CC: | dev-portage |
Priority: | High | ||
Version: | 2.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Martin Walch
2009-02-18 01:05:05 UTC
This looks like a sandbox issue. Sandbox should add a --color=n option for portage to use? This needs support on the sandbox side. It seems to have a static setting inside /etc/sandbox.conf, but perhaps is should use the NOCOLOR environment variable like the portage shell code does: case "${NOCOLOR:-false}" in yes|true) unset_colors ;; no|false) set_colors ;; esac what variable is portage exporting to the environment ? NOCOLOR ? nm, it's already implemented in sandbox-1.3 Sorry for bothering, but I just tried this with sys-apps/sandbox-1.3.7 and I still get those red lines. works fine for me with `emerge --color n foo` I tried different things now. The color remains. Do I need =sys-apps/portage-2.2*? How can I investigate this further? I'm still getting color with --color=n here too, and $T/environment contains declare -x NOCOLOR="true" like it's supposed to. |