24

When I open a terminal window with the GNOME Terminal emulator in the desktop GUI the shell TERM environment variable defaults to the value xterm.

If I use CTL+ALT+F1 to switch to a console TTY window and echo $TERM the value is set to linux.

My motivation for asking is that inside my ~/.bashrc file a variable is used to determine if a color shell is provided or just good old fashioned monochrome.

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

In both the console shell and the Gnome Terminal emulator shell if I type

export TERM=xterm-color
source /.bashrc

both shells change to color mode (something I'd like to have happen always in both).

Where do the default TERM values get set please and where is the best place to change their defaults, if at all possible? There appears to be nothing in the terminal emulator GUI to select or set the default TERM value.

I did consider just adding the line export TERM=xterm-color to the top of my ~/.bashrc file but my gut instinct tells this is not the best solution and my Google searches haven't yet led me to a good answer.

I'm running Ubuntu 15.04 Desktop Edition (Debian Based).

16

In lots of places, depending

On virtual terminals and real terminals, the TERM environment variable is set by the program that chains to login, and is inherited all of the way along to the interactive shell that executes once one has logged on. Where, precisely, this happens varies from system to system, and according to the kind of terminal.

Real, serial, terminals can vary in type, according to what's at the other end of the wire. So conventionally the getty program is invoked with an argument that specifies the terminal type, or is passed the TERM program from a service manager's service configuration data.

  • On van Smoorenburg init systems, one can see this in /etc/inittab entries, which will read something along the lines of

    S0:3:respawn:/sbin/agetty ttyS0 9600 vt100-nav
    The last argument to agetty in that line, vt100-nav, is the terminal type set for /dev/ttyS0. So /etc/inittab is where to change the terminal type for real terminals on such systems.
  • On systemd systems, one can see this in the /usr/lib/systemd/system/serial-getty@.service unit file (/lib/systemd/system/serial-getty@.service on un-merged systems), which reads

    Environment=TERM=vt100
    setting the TERM variable in the environment passed to agetty. This service unit file is where to change the terminal type for real terminals on such systems. Note that it applies to all real terminals that employ this service unit template. (To change it for only individual terminals, one has to manually instantiate the template.)
  • On the BSDs, init takes the terminal type from the third field of each terminal's entry in the /etc/ttys database, and sets TERM from that in the environment that it executes getty with. So /etc/ttys is where one changes the terminal type for real terminals on the BSDs.

Kernel virtual terminals, as you have noted, have a fixed type. Unlike NetBSD, which can vary the kernel virtual terminal type on the fly, Linux and the other BSDs have a single fixed terminal type implemented in the kernel's built-in terminal emulation program. On Linux, that type matches linux from the terminfo database. (FreeBSD's kernel terminal emulation is a limited xterm subset since version 9.)

  • On systems using mingetty or vc-get-tty (from the nosh package) the program "knows" that it can only be talking to a virtual terminal, and they hardwire the "known" virtual terminal types appropriate to the operating system that the program was compiled for.
  • On systemd systems, one can see this in the /usr/lib/systemd/system/getty@.service unit file (/lib/systemd/system/getty@.service on un-merged systems), which reads

    Environment=TERM=linux
    setting the TERM variable in the environment passed to agetty.

For kernel virtual terminals, one does not change the terminal type. The terminal emulator program in the kernel doesn't change, after all. It is incorrect to change the type. In particular, this will screw up cursor/editing key CSI sequence recognition. The linux CSI sequences sent by the Linux kernel terminal emulator are different to the xterm or vt100 CSI sequences sent by GUI terminal emulator programs in DEC VT mode.

Your GUI terminal emulator is one of many programs, from the SSH dæmon to screen, that uses pseudo-terminals. What the terminal type is depends from what terminal emulator program is running on the master side of the pseudo-terminal, and how it is configured. Most GUI terminal emulators will start the program on the slave side with a TERM variable whose value matches their terminal emulation on the master side. Programs like the SSH server will attempt to "pass through" the terminal type that is on the client end of the connection. Usually there is some menu or configuration option to choose amongst terminal emulations.

The gripping hand

The right way to detect colour capability is not to hardwire a list of terminal types in your script. There are an awful lot of terminal types that support colour.

The right way is to look at what termcap/terminfo says about your terminal type.

colour=0
if tput Co > /dev/null 2>&1
then
    test "`tput Co`" -gt 2 && colour=1
elif tput colors > /dev/null 2>&1
then
    test "`tput colors`" -gt 2 && colour=1
fi

Further reading

  • Jonathan de Boyne Pollard (2018). TERM. nosh Guide. Softwares.
  • The following exists in the default .bashrc in Debian jessie: [ -x /usr/bin/tput ] && /usr/bin/tput setaf 1 >&/dev/null && color_prompt=yes. (ncurses 5.9) – thom_nic Mar 16 '17 at 13:20
  • 2
    Also tput Co returns "unknown terminfo capability" in Jessie and Xenial. tput colors and tput setaf 1 both seem to work although I admit I do not understand why. – thom_nic Mar 16 '17 at 14:01
2

Please see https://askubuntu.com/a/614714/398785 for my detailed answer on why I think TERM=xterm-color is the wrong approach and Ubuntu's .bashrc is obsolete. I recommend that you go with TERM=xterm-256color (which is the default since gnome-terminal 3.16, but also safe to use with older gnome-terminals), and adjust your .bashrc accordingly.

  • 1
    +1 for your link. Minor suggestion; the following sentence might be confusing (I first got an impression that you were saying that using .bashrc is obsolete). "Ubuntu's .bashrc is obsolete." – IsaacS Feb 18 '17 at 18:27
  • @IsaacS Do you have any suggestion how to improve it? E.g. would replacing "obsolete" with "outdated" help? – egmont Feb 18 '17 at 20:16
  • It appears that xterm-256color causes htop to mess up its layout like this in Ubuntu 18.04. – OrangeDog Jan 9 at 13:23
  • @OrangeDog In which terminal emulator? This question here and thus my response focuses on GNOME Terminal, whereas the page you linked shows Konsole. The bug looks like the terminal emulator doesn't yet support the REP escape sequence which ncurses started to use around that time. VTE (GNOME Terminal) had already added support for it in Ubuntu 18.04, chances are that Konsole had not. I suspect that your comment with the htop breakage is valid for Konsole but not for GNOME Terminal. – egmont Jan 9 at 14:45
  • @egmont can't speak for the original problem, but I get the same result with WSL's terminal (whatever that is). – OrangeDog Jan 9 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.