gnome-terminal describes itself as $TERM="xterm" even though it is capable of displaying more than 8 colors. You can fix this by pasting this code into ~/.bashrc:
if [ -n "$DISPLAY" -a "$TERM" == "xterm" ]; then
export TERM=xterm-256color
fi
Verify that the fix worked by doing source ~/.bashrc, then tput colors; it should print 256.
Of course, this can do the wrong thing if you’re in a non-256color supporting xterm (or clone). However, various xterm clones that default to identifying as “xterm”, often also set env var COLORTERM (e.g., to “gnome-terminal”), and you can use these combinations to be more confident. My .bashrc logic also tries a run of “infocmp xterm-256color >/dev/null 2>&1”, to verify that the terminal string is recognized (but if your .bashrc logic doesn’t expect to be run on machines lacking such definitions, it’s probably not worth including).
There should actually be a setting in gnome-terminal’s preferences to specify what gnome-terminal gives as the “terminal string”, which should allow you to set it to default to xterm-256color explicitly.
HOWEVER… a few years ago I discovered that VTE, the underlying terminal emulator library used by gnome-terminal (and a goodly number of other emulators), for some reason disregards the TERM setting in the environment set by the application, and decides on its own to hard-code that string to (or other possible values, but “xterm-256color” not among them). The bug report I submitted is at https://bugs.launchpad.net/ubuntu/+source/xfce4-terminal/+bug/778801 and has some details of the failure mechanism (in xfce4-terminal, not gnome-terminal, but they use the same underlying engine). It looks like the libvte problem has since been fixed: https://bugzilla.gnome.org/show_bug.cgi?id=640940 …unless the person who closed that bug wasn’t really paying attention to what the problem really was (as it seems possible)… anyway gnome-terminal may have fixed it or may not have, and even if they did it may not be in the latest distros. :-P
I can’t tell you, after co-maintaining GNU screen for half a year and working in various other low-level terminal projects, how much I’ve come to despise VTE. In the (brief) period during which I maintained screen, my recollection is that most of the bugs found and reported against screen, wound up being VTE bugs (once I’d traced everything through user input -> app -> screen -> term emu -> VTE – thank the FSM for public source code, or I’d have been pulling hair!). As a rule I avoid them. KDE’s Konsole is good in my experience. Many swear by rxvt, but last I checked it didn’t do font antialiasing, which is something I rather like.
It’s a shame, really, because obviously a general-use library to handle terminal emulation should absolutely exist (and, really, should be more general-purpose than just use as a “widget”, to expose its state-machine logic as an API as well); but VTE seems to like to make emulator apps’ decisions for them, and has historically had a number of graphics-related bugs (especially relating rectangular scroll regions, which tends to be exercised regularly by an app supporting split screens, as screen, tmux, vim or emacs do).
Comment by Micah Cowan — January 15, 2015 @ 8:39 pm
This is far more detailed and useful a reply than I had any idea I needed.
Comment by mars — January 28, 2015 @ 2:08 pm