vtty & X terminal color scourge

[Felix Miata]

Once upon a time, I could count on minimal coloring on vttys and X terminals. This
was unaffected by my inclusion of

setterm -foreground white -bold -background blue -blank 59 -store

in .bashrc, which after some years needed to be changed to

tty=$(tty); [ "$tty" != "${tty#/dev/tty[0-9]}" ] && setterm --background blue
--foreground white --bold on --store

NC in DOS around 1985 or so gave me an affection for blue backgrounds instead of
black that has stuck for full screen modes, and for plain text apps whether in
text mode framebuffer or GUI window.

Mostly what I remember from my early Linux days was dead/broken symlinks would be
red and black or red and yellow or white. Otherwise it would be black on yellow or
white in X terminals, and "gray" on black normally on vttys, with an occasional
smattering of white in place of gray or inversion of normal colors when
highlighting was appropriate. I was content.

Now it seems nearly everything has adopted varied foreground colors that are
inadequately contrasty. I noticed https://no-color.org/ via another thread here
today, but have found NO_COLOR=1 exported to have little impact. I tried removing
everything from .bashrc affecting color, but that impacted nothing I tested with.

What bothers me more than anything is that dead symlinks haven't been red, or
anything else to distinguish them, in a long time. With Bookworm on a short path
to release, I'd like to find out if it's possible to get some semblance of old
limited colors behavior back, along with dead symlinks standing out. Apparently
the places to start are bash and dash. Where do these shells get their default
colors globally defined? /etc/dash* doesn't seem to exist. /etc/bash.bashrc seems
only to contain whether colors are enabled or not. Colors don't seem to be under
the purview of console-setup either. Is there any strategy available to limit
coloring of plain text I/O globally that I've missed? Can framebuffers or GUI X
terminals be forced into a 4 color mode that apps cannot ignore? Surely due to
accessibility considerations there must be some way to ensure adequate contrast.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[Greg Wooledge]

On Tue, Apr 04, 2023 at 10:33:26PM -0400, Felix Miata wrote:
> What bothers me more than anything is that dead symlinks haven't been red, or
> anything else to distinguish them, in a long time.

So... you're talking about the colors used by "ls", yes?

If you don't want ls colors at all, you can use "ls --color=never".
You can set that up as an alias/function.

If you DO want colors, just not the ones you're currently getting, then
you need to look at the LS_COLORS environment variable.

According to ls(1), you're supposed to use dircolors(1) to generate
this variable. According to dircolors(1), you're supposed to run
"dircolors --print-database" and read its output to learn how to set
it up.

Looks pretty tedious. Have fun.

[David]

According to adduser(1):
adduser will copy files from SKEL into the home directory

According to adduser.conf(5):
SKEL is the directory from which skeletal user configuration files are copied.
Defaults to /etc/skel

/etc/skel/.bashrc contains:
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" ||
eval "$(dircolors -b)"

The output of 'dircolors -b' looks like:
LS_COLORS='<preconfigured_values>'; export LS_COLORS

The above is how Debian sets up the default value of LS_COLORS.

The values in use, if any, can be seen by
echo $LS_COLORS

Personally I dislike the preconfigured values because they try
to color the output according to BOTH the type of file AND the
filename suffix, which creates a mess. Because the coloring
depends on whether or not the filename is matched.

I create a simpler ~/.dircolors which detects only the type of the file,
and use the above method to control the colors shown by 'ls'. I find it is
very useful for recognising hardlinks as well as good or bad symlinks
in the output of 'ls' command. It's not hard and gives a useful result.

I also configure 'mc' to use the same colors.

[davidson]

On Tue, 4 Apr 2023 Greg Wooledge wrote:
> On Tue, Apr 04, 2023 at 10:33:26PM -0400, Felix Miata wrote:
>> What bothers me more than anything is that dead symlinks haven't
>> been red, or anything else to distinguish them, in a long time.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> So... you're talking about the colors used by "ls", yes?
>
> If you don't want ls colors at all, you can use "ls --color=never".
> You can set that up as an alias/function.
>
> If you DO want colors, just not the ones you're currently getting,
> then you need to look at the LS_COLORS environment variable.

[trimmed interesting stuff about dircolors]

My reading of the OP is that his ls output is not colorised, and he
probably does *not* want to hand-roll some custom color semantics. He
just wants to enable the behavior he remembers.

This section of /etc/skel/.bashrc is pertinent, I think:

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"

alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

#alias grep='grep --color=auto'
#alias fgrep='fgrep --color=auto'
#alias egrep='egrep --color=auto'
fi

I would expect that the alias above for ls (and uncommenting the
aliases for dir, vdir) in one's ~/.bashrc ought to be sufficient to
colorise its output as OP remembers.

In my own accounts' ~/.bashrc, I comment out the ls alias above,
because I do *not* want ls to semantically colorise its output. Having
done that, I have never needed the --color=never alias (in my
accounts).

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

[davidson]

On Wed, 5 Apr 2023 davidson wrote:

> Having done that,
> I have never needed the --color=never alias (in my accounts).

s/alias/option/

[davidson]

On Wed, 5 Apr 2023 davidson wrote:

> On Tue, 4 Apr 2023 Greg Wooledge wrote:
>> On Tue, Apr 04, 2023 at 10:33:26PM -0400, Felix Miata wrote:
>>> What bothers me more than anything is that dead symlinks haven't
>>> been red, or anything else to distinguish them, in a long time.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> So... you're talking about the colors used by "ls", yes?
>>
>> If you don't want ls colors at all, you can use "ls --color=never".
>> You can set that up as an alias/function.
>>
>> If you DO want colors, just not the ones you're currently getting,
>> then you need to look at the LS_COLORS environment variable.
> [trimmed interesting stuff about dircolors]
>
> My reading of the OP is that his ls output is not colorised, and he
> probably does *not* want to hand-roll some custom color semantics. He
> just wants to enable the behavior he remembers.

TLDR: I ate some dog food and it tasted to me like Felix probably does
need to do some hand-rolling after all.

So I open an xterm and enter

$ setterm --background blue --foreground white --bold on --store
setterm: terminal xterm does not support --store

and hit Ctrl-L. Blue sky, white fluffy characters.

With a foreboding sense of doom, I then cd to a directory with a
broken link and try

$ ls --color=auto

and get .... eww.

The attributes are reset. Everywhere that gets redrawn is reset to my
defaults (steelblue1 on black, and no bold). And with a second Ctrl-L
the darkness is complete.

Then I re-read the man page for setterm

--store
Stores the terminal's current rendering options (foreground and
background colors) as the values to be used at
reset-to-default. Virtual consoles only.
^^^^^^^^^^^^^^^^^^^^^

It does indeed work fine in a VT. But the default foreground color
(bold blue?) for directories is unfortunate, given Felix's background
color. (Adding -p to ls helps a little...not enough)

If I launch an xterm with

$ lxterm -bg blue -fg white

then there's no need to use "setterm --store" to fix the rendering
defaults for background/foreground. White-on-blue is then the default
and the "ls --color=auto" test succeeds, modulo the unfortunate
default directory foreground color.

As for setterm's "--bold on", I don't know whether there are
equivalent xterm switches.

[rhkr...@gmail.com]

On Tuesday, April 04, 2023 10:33:26 PM Felix Miata wrote:
> Now it seems nearly everything has adopted varied foreground colors that
> are inadequately contrasty.

+1

--
rhk

Abbreviated sig.

| No entity has permission to use this email to train an AI.

[Dan Ritter]

Felix Miata wrote:
> Once upon a time, I could count on minimal coloring on vttys and X terminals. This
> was unaffected by my inclusion of
>
> setterm -foreground white -bold -background blue -blank 59 -store
>
> in .bashrc, which after some years needed to be changed to
>
> tty=$(tty); [ "$tty" != "${tty#/dev/tty[0-9]}" ] && setterm --background blue
> --foreground white --bold on --store

I'm going to answer a bit more in-depth than you probably want.

As you can tell, setterm affects only the kernel's console
terminals (vt). It doesn't stick around very long, otherwise.

Each terminal or xterm-like-thing has its own settings to define the
mapping between the color commands that it interprets from shell
and applications and the colors that will actually be displayed.

Because the vt driver is part of the kernel, you need to tweak
kernel parameters for this:

$ cat /sys/module/vt/parameters/default_blu
0,0,0,0,170,170,170,170,85,85,85,85,255,255,255,255
$ cat /sys/module/vt/parameters/default_grn
0,0,170,85,0,0,170,170,85,85,255,255,85,85,255,255
$ cat /sys/module/vt/parameters/default_red
0,170,0,170,0,170,0,170,85,255,85,255,85,255,85,255

Line up each of those columns and you get 16 triplets defining
the 24-bit colors mapped into each terminal color slot.

Hold on to that thought, it's time to look at least two other
similar schemes for xterm-like things.

Many xterm-ish things configure color maps via Xresources
(Xrdb):

*.color0: #1b1d1e
*.color1: #f92672
*.color2: #82b414
*.color3: #fd971f
*.color4: #4e82aa
*.color5: #8c54fe
*.color6: #465457
*.color7: #ccccc6
*.color8: #505354
*.color9: #ff5995
*.color10: #b6e354
*.color11: #feed6c
*.color12: #0c73c2
*.color13: #9e6ffe
*.color14: #899ca1
*.color15: #f8f8f2


Yes, an xterm-256color can define colors up to color255. rxvt
does the same.

On the other hand, config like this:

XTerm*foreground: #FFFFFF
XTerm*background: #000000
XTerm*colorBD: #ffc200
XTerm*colorBDMode: 1
XTerm*colorMode: 1
XTerm*colorUL: #FFFFFF
XTerm*colorULMode: 1

defines colors that map to "text" and "background" -- the
defaults that start and take over when other things are erased.


Newer xterm-things use their own config systems, but generally
maintain the ability to map 24-bit RGB color to 16 or 256
colormap entries. That's how you guarantee good contrast on your
systems.

Those colormap entries are called upon by terminal escape codes
emitted by shells or applications. This can cause odd effects:
the colors in an xterm can be different from the colors in an
rxvt and a Wezterm and a gnome-terminal and a alacritty, all on
the same screen, all using the same terminal escape codes to
call for "color3".

Finally, the ls colors require a color-capable terminal, with appropriate
TERM set and recognized in the termcap/terminfo database.
LS_COLOR should be set to AUTO.

The mapping from link type or filename to terminal escape code
is made with a file emitted by dircolors, which has specific
bash and csh variations available. Then you source that file in
your .profile or .bashrc or whatever seems best to you.

Hope that helps.

-dsr-