The termcap data base of terminal descriptions is stored in the file `/etc/termcap'. It contains terminal descriptions, blank lines, and comments.
A terminal description starts with one or more names for the terminal type. The information in the description is a series of capability names and values. The capability names have standard meanings (see section Definitions of the Terminal Capabilities) and their values describe the terminal.
Aside from comments (lines starting with `#', which are ignored), each nonblank line in the termcap data base is a terminal description. A terminal description is nominally a single line, but it can be split into multiple lines by inserting the two characters `\ newline'. This sequence is ignored wherever it appears in a description.
The preferred way to split the description is between capabilities: insert the four characters `: \ newline tab' immediately before any colon. This allows each sub-line to start with some indentation. This works because, after the `\ newline' are ignored, the result is `: tab :'; the first colon ends the preceding capability and the second colon starts the next capability. If you split with `\ newline' alone, you may not add any indentation after them.
Here is a real example of a terminal description:
dw|vt52|DEC vt52:\
:cr=^M:do=^J:nl=^J:bl=^G:\
:le=^H:bs:cd=\EJ:ce=\EK:cl=\EH\EJ:\
:cm=\EY%+ %+ :co#80:li#24:\
:nd=\EC:ta=^I:pt:sr=\EI:up=\EA:\
:ku=\EA:kd=\EB:kr=\EC:kl=\ED:kb=^H:
Each terminal description begins with several names for the terminal type. The names are separated by `|' characters, and a colon ends the last name. The first name should be two characters long; it exists only for the sake of very old Unix systems and is never used in modern systems. The last name should be a fully verbose name such as "DEC vt52" or "Ann Arbor Ambassador with 48 lines". The other names should include whatever the user ought to be able to specify to get this terminal type, such as `vt52' or `aaa-48'. See section Terminal Type Name Conventions, for information on how to choose terminal type names.
After the terminal type names come the terminal capabilities, separated by colons and with a colon after the last one. Each capability has a two-letter name, such as `cm' for "cursor motion string" or `li' for "number of display lines".
There are three kinds of capabilities: flags, numbers, and strings. Each kind has its own way of being written in the description. Each defined capability has by convention a particular kind of value; for example, `li' always has a numeric value and `cm' always a string value.
A flag capability is thought of as having a boolean value: the value is true if the capability is present, false if not. When the capability is present, just write its name between two colons.
A numeric capability has a value which is a nonnegative number. Write the capability name, a `#', and the number, between two colons. For example, `...:li#48:...' is how you specify the `li' capability for 48 lines.
A string-valued capability has a value which is a sequence of characters. Usually these are the characters used to perform some display operation. Write the capability name, a `=', and the characters of the value, between two colons. For example, `...:cm=\E[%i%d;%dH:...' is how the cursor motion command for a standard ANSI terminal would be specified.
Special characters in the string value can be expressed using `\'-escape sequences as in C; in addition, `\E' stands for ESC. `^' is also a kind of escape character; `^' followed by char stands for the control-equivalent of char. Thus, `^a' stands for the character control-a, just like `\001'. `\' and `^' themselves can be represented as `\\' and `\^'.
To include a colon in the string, you must write `\072'. You might ask, "Why can't `\:' be used to represent a colon?" The reason is that the interrogation functions do not count slashes while looking for a capability. Even if `:ce=ab\:cd:' were interpreted as giving the `ce' capability the value `ab:cd', it would also appear to define `cd' as a flag.
The string value will often contain digits at the front to specify padding
(see section Padding) and/or `%'-sequences within to specify how to encode
parameters (see section Filling In Parameters). Although these things are not to be
output literally to the terminal, they are considered part of the value of
the capability. They are special only when the string value is processed
by tputs, tparam or tgoto. By contrast, `\' and
`^' are considered part of the syntax for specifying the characters
in the string.
Let's look at the VT52 example again:
dw|vt52|DEC vt52:\
:cr=^M:do=^J:nl=^J:bl=^G:\
:le=^H:bs:cd=\EJ:ce=\EK:cl=\EH\EJ:\
:cm=\EY%+ %+ :co#80:li#24:\
:nd=\EC:ta=^I:pt:sr=\EI:up=\EA:\
:ku=\EA:kd=\EB:kr=\EC:kl=\ED:kb=^H:
Here we see the numeric-valued capabilities `co' and `li', the flags `bs' and `pt', and many string-valued capabilities. Most of the strings start with ESC represented as `\E'. The rest contain control characters represented using `^'. The meanings of the individual capabilities are defined elsewhere (see section Definitions of the Terminal Capabilities).
There are conventions for choosing names of terminal types. For one thing, all letters should be in lower case. The terminal type for a terminal in its most usual or most fundamental mode of operation should not have a hyphen in it.
If the same terminal has other modes of operation which require different terminal descriptions, these variant descriptions are given names made by adding suffixes with hyphens. Such alternate descriptions are used for two reasons:
Here is a list of standard suffixes and their conventional meanings:
When two terminal descriptions are similar, their identical parts do not need to be given twice. Instead, one of the two can be defined in terms of the other, using the `tc' capability. We say that one description refers to the other, or inherits from the other.
The `tc' capability must be the last one in the terminal description, and its value is a string which is the name of another terminal type which is referred to. For example,
N9|aaa|ambassador|aaa-30|ann arbor ambassador/30 lines:\
:ti=\E[2J\E[30;0;0;30p:\
:te=\E[60;0;0;30p\E[30;1H\E[J:\
:li#30:tc=aaa-unk:
defines the terminal type `aaa-30' (also known as plain `aaa') in terms of `aaa-unk', which defines everything about the Ambassador that is independent of screen height. The types `aaa-36', `aaa-48' and so on for other screen heights are likewise defined to inherit from `aaa-unk'.
The capabilities overridden by `aaa-30' include `li', which says how many lines there are, and `ti' and `te', which configure the terminal to use that many lines.
The effective terminal description for type `aaa' consists of the text
shown above followed by the text of the description of `aaa-unk'. The
`tc' capability is handled automatically by tgetent, which
finds the description thus referenced and combines the two descriptions
(see section Finding a Terminal Description: tgetent). Therefore, only the implementor of the terminal
descriptions needs to think about using `tc'. Users and application
programmers do not need to be concerned with it.
Since the reference terminal description is used last, capabilities specified in the referring description override any specifications of the same capabilities in the reference description.
The referring description can cancel out a capability without specifying any new value for it by means of a special trick. Write the capability in the referring description, with the character `@' after the capability name, as follows:
NZ|aaa-30-nam|ann arbor ambassador/30 lines/no automatic-margins:\
:am@:tc=aaa-30:
Each application program must read the terminal description from the data base, so a change in the data base is effective for all jobs started after the change is made.
The change will usually have no effect on a job that have been in existence since before the change. The program probably read the terminal description once, when it was started, and is continuing to use what it read then. If the program does not have a feature for reexamining the data base, then you will need to run it again (probably killing the old job).
If the description in use is coming from the TERMCAP environment
variable, then the data base file is effectively overridden, and changes in
it will have no effect until you change the TERMCAP variable as
well. For example, some users' `.login' files automatically copy the
terminal description into TERMCAP to speed startup of applications.
If you have done this, you will need to change the TERMCAP variable
to make the changed data base take effect.
Go to the first, previous, next, last section, table of contents.