In playing with the curses library, I discovered that if a default color is changed (say COLOR_BLUE, for example) using init_color, that changed color will continue to be used across stopping and restarting my program if I don't reset it back to its original definition. Even creating a new terminal window in which to run the program, the color of blue shows up as defined in the original windows. It even survives running a completely different program.
How is this happening? I would have thought the original definition would be used upon starting a new instance. I can only surmise that these default colors are cached somewhere at the OS level. Can someone explain what is happening here that allows this to happen?
I'm running this on a Centos 7.6 distro.
The colors are maintained/cached/whatever by a given terminal.
If the terminal description has this feature:
orig_colors oc oc Set all color pairs
to the original ones
that would be sent by the ncurses library as part of exiting curses mode.
It also might be sent by reset (or tput reset) command as part of the rs1 string. That's not automatic (and those commands do nothing special with color other than as a side-effect of the initialization and reset strings).
xterm supports a control sequence for resetting palettes back to their default, which was added to the terminal description in
2016-04-23
# + add 'oc' capability to xterm+256color, allowing palette reset for
# xterm -TD
referring to this:
oc=\E]104\007,
That uses OSC 104, which was developed for xterm in patch #252 (2009/12/7):
add OSC 104, for resetting ANSI/16/88/256 colors to default.
However, in discussing CentOS (RHEL), you have to keep in mind that it doesn't get updates for things like that: