Stop implicitly manipulating NO_COLOR/NOCOLOR
#1188
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mgorny
requested review from
floppym,
arthurzam,
zmedico,
thesamesam and
ajakk
ajakk
approved these changes
Nov 26, 2023
zmedico
approved these changes
Nov 26, 2023
|
We could also do the same in |
thesamesam
approved these changes
Nov 29, 2023
I wasn't sure whether I ought to touch it since it doesn't really affect ebuilds and I don't know if |
Stop implicitly forcing `NO_COLOR` and `NOCOLOR` in ebuild environment.
This is undesired for several reasons:
1. It makes it impossible to control color for emerge output
independently of command output, e.g. when one goes to a pty while
the other goes to logs.
2. It makes it impossible to get color output in logs when running
`emerge --jobs ...`.
3. Forcing `NO_COLOR=1` turns out to cause random test failures,
and while fixing them is commendable, it is a pain for arch testing
and it is currently blocking stabilization requests.
With the new approach, the color output in programs is consistent
between using ``--jobs`` or ``--quiet-build``, and not. Therefore,
both cases generate uniform logs. In order to obtain logs free of color
codes, one can either filter them via `ansifilter(1)` (as the manpages
already recommend) or explicitly set `NO_COLOR`.
Furthermore, one can combine color-free build output (for clean logs)
with colorful emerge output by using:
NO_COLOR=true emerge --color y ...
Bug: https://bugs.gentoo.org/918515
Signed-off-by: Michał Górny <mgorny@gentoo.org>
mgorny
force-pushed
the
no-magic-nocolor
branch
from
0e0eee1
to
9c02566
Compare
|
ok, wfm, ship it |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stop implicitly forcing
NO_COLORandNOCOLORin ebuild environment. This is undesired for several reasons:It makes it impossible to control color for emerge output independently of command output, e.g. when one goes to a pty while the other goes to logs.
It makes it impossible to get color output in logs when running
emerge --jobs ....Forcing
NO_COLOR=1turns out to cause random test failures, and while fixing them is commendable, it is a pain for arch testing and it is currently blocking stabilization requests.With the new approach, the color output in programs is consistent between using
--jobsor--quiet-build, and not. Therefore, both cases generate uniform logs. In order to obtain logs free of color codes, one can either filter them viaansifilter(1)(as the manpages already recommend) or explicitly setNO_COLOR.Furthermore, one can combine color-free build output (for clean logs) with colorful emerge output by using:
Bug: https://bugs.gentoo.org/918515