Dear Maintainer,

The apt command shows colors on monochrome terminals (even on a dumb terminal),
please avoid this. Included is a patch which i believe will solve the problem
and only allows output on terminals which actually have 'color' in them; the
same logic as to when to color the default bash prompt.
I have not tested this patch.

Kind regards,
Axel
--- private-output.cc.orig	2022-05-10 14:18:27.611767218 +0200
+++ private-output.cc	2022-05-10 14:20:17.511703336 +0200
@@ -86,7 +86,8 @@
       SigWinch(0);
    }

-   if(!isatty(1))
+   char *term = getenv("TERM");
+   if(!isatty(1) || strstr(term, "color") == NULL)
    {
       _config->Set("APT::Color", "false");
       _config->Set("APT::Color::Highlight", "");

Hi

I'm not really involved with apt development, but I've strong opinions
when it comes to terminal applications.

The value of $TERM refers to a terminfo / termcap definition / file. If
a terminal supports color, and which escape sequences they need for
them, is specified inside those files.
The name of the files (and thus the value of the $TERM variable), does
not necessarily have to contain "color" if the terminfo / termcap
definition specify the capabilities for color, and vice versa.
Additionally, not all terminals may use the same escape sequence for
colors either.

I think the root cause of the problem is escape sequences being
hardcoded in apt, that simply should never be done. An application
should always make use of the terminfo database when outputting any
escape sequence.
This will also make it trivial not to output escape sequences on dumb
terminals, since there'll simply be no cap / escape sequence in the
terminfo definition to output in that case.
For colors, this may be helpful:
https://stackoverflow.com/questions/42734416/how-to-set-colors-in-terminal-using-terminfo

It seams there are a few places with hard coded escape sequences, but
it's not too bad yet:
https://salsa.debian.org/search?search=033&group_id=2051&project_id=228&scope=&search_code=true&snippets=false&repository_ref=main&nav_source=navbar

Regards,
Daniel Abrecht

You mean monochrome terminals such as "xterm", "rxvt", "linux", ...?

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.

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.


Meow!

apt respects https://no-color.org/ NO_COLOR environment variable,
and I believe this is the way to go for this.

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

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
        # We have color support; assume it's compliant with Ecma-48
        # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
        # a case would tend to support setf rather than setaf.)
        color_prompt=yes
    else
        color_prompt=
    fi
fi

Hi,

Thanks for your quick response and thoughtful comments,

Yes, and screenreaders or other accessibility tools. A linux/unix terminal can
be a great interface for people with visibility problems.

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).

Oh that's really nice. I've requested this via other channels so I'm glad
it is implemented now. Thanks!

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

Hi,

Regarding terminal capabilities,

The 'proper' way would be to query the terminfo entry Co I think. The best way
to make a terminal program color capable would be to use a terminal library
like ncurses which handles this for you and has a function `has_colors(void);`
which does the right thing(tm) :)

Kind regards,
Axel

The terminfo entries stopped being maintained by late 80's.  And even if
they were, every new terminal would need to wait several years before it can
have its definition known by operating systems (today, distributions).
The effect?  Most terminals identify as "xterm", "xterm-256color", or
"rxvt".  For example both libvt (Gnome-Terminal, etc) and Konsole claim to
be an xterm...

And even if $TERM->terminfo were usable, a serial console has no way to pass
env vars.  As an install/rescue tool, apt gets run over a serial console
pretty often.

Thus, using terminfo is definitely not a "Right Thing" this millenium.
Most new programs just hardcode the codes, assuming a vt100-like terminal
with a common set of capabilities.  This includes color, as the last
terminal without color that I remember was Windows 3.X/95's telnet.exe
(which, per the vt100 language, ignored unknown SGR codes gracefully).

Ie, this patch doesn't work, and I see no way to make it work.


Meow!

Hi,

I think you are mistaken here. There's no need to pass environment variables,
if you run a serial terminal you are supposed to set the proper type, by using
systemd's Environment setting in serial-getty@service or otherwise
(i'm more used to gettytab). Not the other way around on the client side.
A common setting, certainly for a rescue terminal, is vt100. When you look at
terminfo you'll see it defines some common things like how to handle backspace
(this should sound familiar when you've been running *nix for some
time as it was
a big problem in the dialup era). When your function or arrow keys don't work
properly for instance this is the way to fix that.

Using curses (and therefor terminfo/termcap) has been the proper way to
handle different terminals for years. Using hardcoded ansi only has become
popular the last decade or so. A vt100 does *not* support color, a thing which
terminfo tells you when you run infocmp.

$ infocmp | grep color
#       Reconstructed via infocmp from file: /lib/terminfo/s/screen-256color
screen-256color|GNU Screen with 256 colors,
        colors#0x100, cols#80, it#8, lines#24, pairs#0x10000,

$ export TERM=vt100
$ infocmp | grep color
$

Even if there are terminals which are basically 'dumb' (a serial
braille terminal
comes to mind) it should be possible to disable all color output by setting
TERM=xterm-mono when you run an xterm. It's quite rude to use color on a
monochrome terminal like this.

The patch was the smallest addition I could think about without including
a dependency on curses. Please reconsider using color only on terminals
which 'want' to use them.

Kind regards,

Axel

Am 2022-05-16 18:29, schrieb Adam Borowski:
from ncurses-term,
the ncurses package seams still to be maintained and getting updates
(https://tracker.debian.org/pkg/ncurses).
Looking at the upstream release notes, which state that they are form
October 21, 2021, quiet a few new ones have been added:
https://invisible-island.net/ncurses/announce.html#h3-database

Therefore, it seams terminfo entries are still being maintained to this
day.

It's not like new kinds of real terminals are produced anymore, at least
I don't know of any.
In case of terminal emulators, they have to be packaged anyway, so a the
terminfo file
can be added to the appropriate package at the same time.

There are terminals who choose to be compatible to xterm. It probably
has more to do with
programs wrongly hardcoding escape sequences than anything else, and
there is nothing wrong
with making an xterm-compatible terminal. However, that doesn't change
the fact that other
terminals exist as well. In addition to this, if terminals implement
special new escape sequences
(think about recent things like sixel for example), there is no way
around an appropriate
terminfo to make known that it's supported.

It works automatically for terminal emulators. Tools like getty can set
the TERM variable.
Yes, only the operator knows what is connected to a serial console. In
cases where it is not
known, personally, I think a dumb terminal should be assumed to maximize
compatibility.
But I guess in most cases, something like vt100 or xterm will often
work, so I don't mind it
too much. People who really need to can still override it. It's not
automagic, but it works.

I'm happy to report, that aside from apt, I'm not using any of those
programs.
Yes, there are lazy modern programmers insisting on doing it wrong.
Those programs
will simply fail on various terminals. Let's not promote that, it won't
right it.

Setting TERM works, it works well, and it solves the problem in the best
way possible.
Just because it can't always do it automatically, doesn't mean we should
give up and leave things unfixably broken.
terminfo is the right thing. It is the only way to deal with these
terminals. This will never change.

Regards,
Daniel Abrecht

And how, pray tell, may I know in advance what terminal will be used on the
other end of the serial link?  Especially if it's a box people ssh into from
random places, using a plethora of various terminals on their side?
That's the most typical setup these days.

"vt100" is not a common setting for some decades now, and it differs quite a
bit from what modern terminals offer.  Both by lacking capabilities people
take for granted, and by having some no sane terminal bothers to implement
today.  Thus it's a pretty bad choice.

Most function keys are not representable via termcap nor terminfo, and TERM
strings are overloaded anyway between diverse terminals (like xterm vs libvt
vs konsole vs ...).

Until late 80s maybe.  By the 90s using curses in a diverse setting meant
lackingdetailslikespaces (this example is IRIX curses vs Linux console), as
vendors stopped maintaining termcap databases.

vt100 also stopped being manufactured before the average user has been even
born.

The only way I can see your idea to work, would be a list of ancient
terminals that lack color (either handcrafted or queried via termcap), and
relying on the user setting one of those.  But that way would be way way too
niche to bother implementing in apt, I'd say.

Thus, as ways to disable color go, I don't see your patch as viable.


Meow!

Op wo 25 mei 2022 21:36 schreef Adam Borowski <kilobyte@angband.pl>:

You can't really in that case; the terminal emulator will set the proper
value. Maybe it's wise to run tset in that case so if it's not what is
expected one can set it themselves. Or maybe they have set them themselves
as I do;

I agree that this is the most common setup but it doesn't change a thing
really. I set my x terminals to xterm-mono. When I use colors many things
become unreadable. Switching between black on white and white on black is
also troublesome without creating specialised palettes.

The only way I can see your idea to work, would be a list of ancient

Or the other way around as I proposed. The entire problem of knowing what
and how to use color goes away when curses is used. Would you accept a
patch for using that instead?

Kind regards,

Axel

1010806@bugs.debian.org

I've forgot about this but how about the following?

#include <curses.h>
#include <term.h>

int
ncolors(void)
{
        int ncolors = -1;

        if (setupterm(NULL, 1, NULL) == OK) {
                ncolors = tigetnum("colors");
                del_curterm(cur_term);
        }

        return ncolors;
}

This doesn't initialise the terminal so you can still do the
progressbar without clearing the screen and/or use hardcoded ansi
codes for colors if you want. It returns the number of colors for the
used terminal or -1 if color is not supported. Maybe the progressbar
should be optional in that case too. I think it would be a nice
addition and one doesn't have to use apt-get  and/or apt-cache
instead.
Also, maybe using italics, bold and reverse video instead of colors
can be considered? They usually do the right thing with either
background. Anyway, I hope you can implement the above function to
make at least monochrome and/or dumb terminals behave.

Kind regards,
Axel

Using 'ncolors' for both function and variable isn't really nice but
as is the function will exit when you use it with an unknown terminal
which might not be ok. Maybe using the following would be better;

#include <curses.h>
#include <term.h>

int
ncolors(void)
{
        int err, n = -1;

        if (setupterm(NULL, 1, &err) == OK) {
                n = tigetnum("colors");
                del_curterm(cur_term);
        }

        return n;
}

You should also link ncurses (which brings in a bit of cruft).
Kind regards,
Axel

On Mon, Jan 29, 2024 at 1:53 PM Axel Scheepers <axel.scheepers76@gmail.com> wrote: