[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: vtty & X terminal color scourge



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-


Reply to: