Bug#1010806: apt: Avoid color output on monochrome terminals
Hi,
Thanks for your quick response and thoughtful comments,
On Tue, May 10, 2022 at 6:04 PM Julian Andres Klode <jak@debian.org> wrote:
> On Tue, May 10, 2022 at 04:54:21PM +0200, Adam Borowski wrote:
> > You mean monochrome terminals such as "xterm", "rxvt", "linux", ...?
Yes, and screenreaders or other accessibility tools. A linux/unix terminal can
be a great interface for people with visibility problems.
> > I haven't seen an actual monochrome terminal since the first half of the
> > 90's. But even those accepted color codes and gracefully ignored them.
> > To find a terminal that speaks a different language you'd need to go
> > another decade into the past.
My first crt one was a vt-52 compatible :)
There are other uses however like the mentioned accessibility tools. It's the
same reason some people like/have to use the ed editor or the edbrowse(r).
> > Thus, I guess that what you want is some global switch to disable color
> > in programs. But there's no common characteristic of a terminal that'd
> > allow autodetecting your wishes.
>
> apt respects https://no-color.org/ NO_COLOR environment variable,
> and I believe this is the way to go for this.
Oh that's really nice. I've requested this via other channels so I'm glad
it is implemented now. Thanks!
> For completeness, my bashrc does the following, so it looks at
> tput setaf 1 (change color to red to see if there's color available).
>
> case "$TERM" in
> xterm-color|*-256color) color_prompt=yes;;
> esac
I'm referring to:
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac
from /etc/skel/.bashrc (which imho also should avoid using color at all :).
The part you refer to is for forcing color output.
Thanks again for checking for NO_COLOR, I hope this can be used for
more things in the future.
Kind regards,
Axel
Reply to: