restorepalette (1) - Linux Man Pages
restorepalette: set the color palette for textmode.
NAMErestorepalette - set the color palette for textmode.
DESCRIPTIONrestorepalette without arguments sets the standard VGA palette. This can be useful if it is somehow messed up.
With a filename argument a custom palette can be loaded (feature added by Charles Blake <chuckb [at] alice.wonderland.caltech.edu>).
This allow a user to set up a file that looks like this one (These color map definitions are the same as the default VGA ones. Alter to suite personal tastes). The first column contains the number of the color to set, then follow three integers in range 0 - 63 (lowest to highest intensity) for red, green, blue.
0 0 0 0 # black
1 0 0 42 # blue
2 0 42 0 # green
3 0 42 42 # cyan
4 42 0 0 # red
5 42 0 42 # magenta
6 42 21 0 # brown
7 42 42 42 # white
8 21 21 21 # bright black
9 21 21 63 # bright blue
10 21 63 21 # bright green
11 21 63 63 # bright cyan
12 63 21 21 # bright red
13 63 21 63 # bright magenta
14 63 63 21 # bright brown
15 63 63 63 # bright white
The inline comments are the only kind of allowed, as I use a little fscanf(3) trick to get them. Blank lines are ok, but not pure comment lines. See the comments in my code, also.
This allows people to set up custom palettes for use in virtual console text modes. I use it all the time. When combined with a color-syntax editor like jed-0.97+ or color-ls, etc., being able to choose your own text-mode palette is quite a bonus. I set mine up via restorepalette /etc/palette in my /etc/rc. If the program is given the correct permissions, then individual users can have restorepalette ~/.palette or some such thing in their shell startup files. Of course, it shouldn't be done when starting remote shells or when under X, so some kind of test that TERM is a virtual console is needed for that case.
This manual page was edited by Michael Weller <eowmob [at] exp-math.uni-essen.de>. The exact source of the referenced utility as well as of the original documentation is unknown.
It is very likely that both are at least to some extent are due to Harm Hanemaayer <H.Hanemaayer [at] inter.nl.net>.
Occasionally this might be wrong. I hereby asked to be excused by the original author and will happily accept any additions or corrections to this first version of the svgalib manual.