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 terminals
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.
systemd's variability
The serial-getty@.service
service unit file, or drop-in files that apply thereto, is where to change the terminal type for real terminals on systemd systems. Note that such a change applies to all terminal login services that employ this service unit template. (To change it for only individual terminals, one has to manually instantiate the template, or add drop-ins that only apply to instantiations.)
systemd has had at least four mechanisms during its lifetime for picking up the value of the TERM
environment variable. At the time of first writing this answer, as can be seen, there was an Environment=TERM=something
line in the template service unit files. At other times, the types linux
and vt102
were hard-wired into the getty
and serial-getty
service unit files respectively. More recently, the environment variable has been inherited from process #1, which has set it in various ways.
As of 2020, the way that systemd decides what terminal type to specify in a service's TERM
environment variable is quite complex, and not documented at all. The way to change it remains a drop-in configuration file with Environment=TERM=something
. But where the default value originates from is quite variable. Subject to some fairly complex to explain rules that involve the TTYPath=
settings of individual service units, it can be one of three values: a hardwired linux
, a hardwired vt220
(no longer vt102
), or the value of the TERM
environment variable that process #1 inherited, usually from the kernel/bootstrap loader.
(Ironically, the getttyent()
mechanism still exists in the GNU C library, and systemd could have re-used the /etc/ttys
mechanism.)
kernel virtual terminals
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 since version 9 has been teken
. Prior to version 9 it was cons25
OpenBSD's is pccon
.)
- 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 used to be able to see this in the
/usr/lib/systemd/system/getty@.service
unit file (/lib/systemd/system/getty@.service
on un-merged systems), which read 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. (In fact, they are highly idiosyncratic and non-standard, and different both to all real terminals that I know of, and to pretty much all other software terminal emulators apart from the one built into Linux.)
GUI terminal emulators
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.
X11 resources have a name which consists of a series of components separated by a dot, such as xterm.vt100.geometry
. The first component is the name of the application, the second component is a widget in that application, and the last component is a property of the widget. Widgets can be nested, so there can be more than three components, or just two for a property of the application.
Specifications of X resources can apply to a single resource or to a set of resources matching a pattern. There are two ways to make a specification apply to multiple resources.
You can explore the resource tree of an application that supports the editres protocol with editres
. Few applications support this protocol, but Xterm is one of them.
It's possible for a given resource to be matched by multiple patterns. In this case, precedence rules apply. See the manual for the full rules.
In your case, it's likely that there's another entry somewhere that is a closer match for xterm.vt100.geometry
than xterm*VT100.geometry
, and that match is overriding your setting. The others have no other setting so whatever you do wins.
Best Answer
For the most part, you should not set
TERM
manually. The variable is always set automatically, and there is only a narrow set of circumstances where the default value is incorrect.The value of
TERM
needs to be referenced in the system's terminfo database (or for a few old-fashioned system, in the termcap database). Terminfo and Termcap map terminal types to the description of terminal capabilities that applications use. The value ofTERM
is the terminal type.The main reason why you might sometimes need to change
TERM
is if you log in remotely, when the local machine and the remote machine have different terminal databases.Another reason, which is related to the previous one, is that sometimes there are multiple similar entries for a terminal, with slightly different capabilities. This tends to happen mostly when a new terminal comes up which is compatible with an existing terminal, but has more features. You then get a choice between using the traditional name, which all machines understand, but which advertises only the traditional features, or the newer name, which advertises all the new features but which some machines won't understand.
An example of this is xterm with 16 colors vs xterm with 256 colors. A traditional xterm supports only 16 colors, so that's what the
xterm
terminal database specifies. Changing thexterm
entry would make users of the newer xterm versions happy, but would break the configuration of users of older xterm versions who log in remotely. Switching to a new name —xterm-256color
— provides the newer capabilities whenever available, but is not recognized if you log in remotely to machines with an older terminal database. Because there is no solution that can satisfy everyone, you get a choice: either stick withxterm
and don't get the 256 colors, or usexterm-256color
which doesn't work if you log in to remote machines that don't support it.Leaving the default value of
xterm
and setting thetermName
resource toxterm-256color
(which causes the environment variableTERM
to be set to the same value) are thus both sensible choices. SettingTERM
to arbitrary values wouldn't work, but bothxterm
andxterm-256color
make sense.