There is a bunch of questions about how to enable 256 colors in various environments. I want to do the opposite: Restrict all applications to my carefully handpicked 16 color palette. The reason is that I want to prevent applications from using colors that are hard to read.

I tried to set TERM=xterm in bashrc but that had no noticeable effect.

  • 1
    I tried running TERM=linux tput colors and it said that there are only 8 colors. So setting the TERM environment variable to linux should stop programs from attempting to use 256 colors. But there will only be 8 colors not 16, and there could also be some uncommon things that a Linux tty can do the terminal emulator can't.
    – Oskar Skog
    Jul 11, 2020 at 14:06
  • And because I'm an idiot, I tried with TERM=linux before TERM=xterm-16color. You should probably use TERM=xterm-16color.
    – Oskar Skog
    Jul 11, 2020 at 14:07
  • That won't have much effect on typical hard-coded applications (such as GNU ls), which have a single color palette matching multiple TERM values. Jul 12, 2020 at 17:20

2 Answers 2


This is impossible, for several reasons.

There are various colour systems still in use that applications use to tell terminals what colour to use, the original 1970s 8-colour system from ECMA-48:1976, the AIXterm 16-colour system from the 1990s, the ISO 8613-6/ITU T.416 indexed colour system from the 1990s, and the ISO 8613-6/ITU T.416 direct colour system from the 1990s.

First reason: Only three out of these four even involve a palette at all. Direct colour does not. If your application is emitting direct colour control sequences, there is no way to change its colours short of directly reconfiguring or recoding the application (somehow) to change the colours used. (A few terminal emulators do not support direct colour very well, and involve the palette when they are told things using direct colour control sequences. This does not give one any reasonable form of effective control, however, as it is a nearest match mechanism; and those terminal emulators are not the general case.) There's no common "colour scheme" user preference system for TUI applications (as there is in some GUIs for GUI applications) moreover.

Second reason: The palette isn't 16 entries. Almost all terminal emulators that have such a palette have a VGA-style 256-entry colour palette, and it is the same one that is used for 8-colour and 16-colour control sequences. (The Microsoft Terminal people did once muse on the possibility of making them separate, but no terminal emulator author that I know of has actually done this.) There is no modulo 16 nor modulo 8 limit in the palette itself.

Third reason: 16 colours is not simple. Originally (glossing over a few details) there were 8 standard colours when colour terminals came along. 16 colours is an extension, and there is a whole mess of confusion relating to conflating boldface, blinking, and underline text attributes with colours. The messy history and details are beyond the scope of this answer, and there is pressure to clean up the mess at long last, but the upshot is that there is currently disagreement over when and how one gets at least 8 of those 16 colours. Your applications won't necessarily agree with you.

Ironically, your idea of setting TERM to linux is particularly bad, as it is one of the very ways to cause a particularly egregious disagreement. (That is, moreover, ignoring the fact that setting the wrong terminal type that does not match the terminal in use is the wrong thing to do, which is an answer in its own right.) It is one of the ways of telling applications to not use the AIXterm 16-colour system, but to use an 8-colour system that abuses attributes for alternate colours.

Fourth reason: 16 colours is not simple. A few terminal emulators, sadly, alter the first 16 entries in the palette on the fly according to things like the "light/dark background" setting of the screen, and the reverse video attribute. Because they know better than you and your applications. ☺

Fifth reason: Terminals and terminal emulators do not make this configurable. It's not possible to tell a terminal (emulator) to not understand 256-colour indexed colour or 24-bit direct colour when an application emits such a control sequence. No terminal emulator that I know of has a switch that turns its control sequence processing for colour off.

The only thing that one can do, therefore, is (attempt to) tell applications not to emit the control sequences, rather than tell terminals to refuse to understand them. The theory goes that one specifies a (correct) terminal type with a -16color or -mono or suchlike suffix in the TERM environment variable, and because that limits what the terminfo library yields as the control sequences for specifying colour, applications simply don't know how to specify more colours than that. Which brings us to the sixth reason.

Sixth reason: Applications tend to hardwire colour and not use terminfo. Again, there's a whole mess of history behind this that is outwith the scope of this answer, but the idea that everyone uses the setab and setaf capabilities of terminfo is just a pipe dream. A lot of applications hardwire colour control sequences directly into their code. This especially includes applications written in programming languages such as (for examples) Python and Go, which tend to use (semi-)portable libraries in those languages that both postdate terminfo and that don't operate from a humongous database of terminal types. (I encountered this Python one, for instance, just the other day.) But one can even find it done in some common GNU tools written in C.


From a comment: TERM=linux works. I also tried TERM=xterm-16color but it had no effect).

  • This technically does work, but it comes with all kinds of side effects (e.g. curses apps stay visible after closing)
    – tobib
    Jul 12, 2020 at 18:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .