tmux, TERM and 256 colours support

There is some information on 256-color support in the tmux FAQ.

Detecting the number of colors that the terminal supports is unfortunately not straightforward, for historical reasons. See Checking how many colors my terminal emulator supports for an explanation. This means that

• tmux cannot reliably determine whether the terminal supports more than 8 colors;
• tmux cannot reliably communicate to the application that it supports more than 8 colors.

When you're in tmux, the terminal you're interacting with is tmux. It doesn't support all of xterm's control sequences. In particular, it doesn't support the OSC 4 ; … control sequence to query or set color values. You need to use that while directly running in xterm, outside tmux.

If you run tmux -2, then tmux starts with 256-color support, even if it doesn't think that your terminal supports 256 colors (which is pretty common).

By default, tmux advertises itself as screen without 256-color support. You can change the value of TERM in .tmux.conf to indicate 256-color support:

set -g default-terminal "screen-256color"

You can use TERM=xterm-256color or TERM=screen-256color on Ubuntu. These values will only cause trouble if you log in to a remote machine that doesn't have a termcap/terminfo entry for these names. You can copy the entries to your home directory on the remote machine; this works with most modern terminfo implementations.

# From the Ubuntu machine to a machine that doesn't have *-256color terminfo entries
ssh somewhere.example.com mkdir -p .terminfo/s .terminfo/x
scp -p /lib/terminfo/s/screen-256color somewhere.example.com:.terminfo/s/
scp -p /lib/terminfo/x/xterm-256color somewhere.example.com:.terminfo/x/

I'm impressed about how richfully formatted and detailed the answers (and the question!) are. While they provide valuable info and solutions about the tools you mentioned, they provide very little insight about what the heck is going on, and, most importantly, why things are (somewhat) working for some tools when they supposedly should not.

So here's some insights on your fundamental questions:

• What a terminal supports and what it reports are different things. Gnome terminal for example is capable of displaying 256 colors, but it announces itself to the environment (via $TERM variable) as an xterm emulator (8 color).

• Tools like tput follow whatever TERM is set to: tput colors may print 8, while env TERM=xterm-256color tput colors will print 256, regardless if your terminal actually supports such capabilities.

• vim also follow TERM by default, but as you told it to use 256 colors (via the flag or the set t_Co=256), it will use 256 colors. And it works because your terminal actually supports that.

• tmux, just like Gnome Terminal, also by default reports itself as an 8-color terminal. But, unlike Gnome Terminal, it only enables 256-color capability if you use the -2 flag, which also makes it report itself as an xterm-256color compatible emulator.

• xterm, as in the terminal emulator software for the X11, supports 256 colors, for sure. But xterm as in TERM=xterm is an 8-color "standard". It means the capabilities of the original xterm. When it was upgraded to support 256 colors, a long time ago, it coined the xterm-256color term for that.

So it all comes down to:

• What capabilities your terminal actually supports (and is enabled to do so)

• How it reports such capabilities to the environment via TERM

• How tools interpret TERM and adjust themselves accordingly.

• As you can infer from the above, avoid hammering export TERM=xterm-256color in your ~/.bashrc and such scripts. As those files are executed regardless of the terminal you're actually using, it will make all your terminals, including remote connections from Windows with Putty, Linux console terminal, etc, report themselves as xterm-256color compatible. Which may be true for some but certainly not for all. For example, getty, the linux console you access with CTRL+ALT+1..6, does not.

• Terminals should report themselves as the "standard" they are most compatible with. If you know they can handle 256 colors, configure them to advertise as such.

Last but not the least, an amazing reading about TERM and 256 colors is:

http://blog.sanctum.geek.nz/term-strings/

http://blog.sanctum.geek.nz/256-colour-terminals/

I will provide a complementary answer which addresses only your additional experiments insofar as they relate to the solarized directory colors.

Setup

We have the same color output from the test script. The only difference is that I used lxterminal on Openbox with slim, xcompmgr and no DM. Therefore I can't easily set a custom palette like you did as that terminal emulator doesn't offer those settings in a GUI and there is no specific theme for it (those only exist for a few terminal emulators). So I just use some translucency, undecorated terminals and that blue as foreground color with a blue Gentoo background. Since I can't use the ansi versions of the color files, I've focused exclusively on getting results with dircolors.256dark i.e the "degraded" simple version.

I used the following relevant configuration and the inconsolata medium font:

echo $TERM
xterm

.bashrc:
eval `dircolors /path/to/dircolors.256dark`

.vimrc:
set t_Co=256
let g:solarized_termcolors=256
syntax enable
set background=dark
colorscheme solarized

.tmux.conf:
nothing at all related to colors!
start tmux with "tmux -2"

Dircolors

The image below shows what happens both inside and outside of tmux with these settings. The first third to the left shows undecorated lxterminal windows stacked vertically (3). To the right you have a tmux assembly showing the same identical programs(3) I have also included a solarized xterm¹ showing nano using the .Xresources file included in the full package (and sampling it with xrdb -load ~/.Xresources):

please right click/view image to inspect at full resolution

The first terminal in the top left corner showcases the default directory colors. Just below is the degraded solarized version. Except for the pink on blue background for .c files I added, it is identical to what is expected from this(see image below for reference). Compared to the defaults, it builds further on the extended attributes i.e. bold/light/reverse etc. and the colors are different obviously. The default color assignment for .txt files in many distribution is green, but it should be grey instead when solarized. An ansi file rendering a .txt file as green is either not rendering correctly or not rendering at all. The right hand-side results you showed are the correct ones(256dark) in relation to the following reference:

solarized "degraded" dircolors reference map

Observations

With the configuration I used, the results appear identical inside and outside tmux(I have reversed comments (#) in vi but otherwise the plugin behaves as it should and the multiplexer has no impact on this). Fonts play a huge role in the solarized features definition, and a good font is required to maximize the experience. The solarized directory colors using the 256dark file match the reference and requires no specific terminal emulator configuration.

---

Conclusion

Actually the ansi rendering of the directory colors is just completely different from the degraded solarized(256dark). So much so that under ansi .txt files are green. One cannot be used to validate the rendering of the other. Both solutions need different configuration and produce entirely different results.