|
A Sample
Entry
The following entry, describing an ANSI-standard terminal, is
representative of what a terminfo entry for a modern
terminal typically looks like.
ansi|ansi/pc-term compatible with color,
mc5i,
colors#8, ncv#3, pairs#64,
cub=\E[%p1%dD, cud=\E[%p1%dB, cuf=\E[%p1%dC,
cuu=\E[%p1%dA, dch=\E[%p1%dP, dl=\E[%p1%dM,
ech=\E[%p1%dX, el1=\E[1K, hpa=\E[%p1%dG, ht=\E[I,
ich=\E[%p1%d@, il=\E[%p1%dL, indn=\E[%p1%dS, .indn=\E[%p1%dT,
kbs=^H, kcbt=\E[Z, kcub1=\E[D, kcud1=\E[B,
kcuf1=\E[C, kcuu1=\E[A, kf1=\E[M, kf10=\E[V,
kf11=\E[W, kf12=\E[X, kf2=\E[N, kf3=\E[O, kf4=\E[P,
kf5=\E[Q, kf6=\E[R, kf7=\E[S, kf8=\E[T, kf9=\E[U,
kich1=\E[L, mc4=\E[4i, mc5=\E[5i, nel=\r\E[S,
op=\E[37;40m, rep=%p1%c\E[%p2%{1}%-%db,
rin=\E[%p1%dT, s0ds=\E(B, s1ds=\E)B, s2ds=\E*B,
s3ds=\E+B, setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p8%t;11%;%?%p9%t;12%;m,
sgr0=\E[0;10m, tbc=\E[2g, u6=\E[%d;%dR, u7=\E[6n,
u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%p1%dd,
Entries may continue
onto multiple lines by placing white space at the beginning of each
line except the first. Comments may be included on lines beginning
with ‘‘#’’. Capabilities in terminfo
are of three types: Boolean capabilities which indicate that the
terminal has some particular feature, numeric capabilities giving
the size of the terminal or the size of particular delays, and
string capabilities, which give a sequence which can be used to
perform particular terminal operations.
Types of
Capabilities
All capabilities have names. For instance, the fact that
ANSI-standard terminals have automatic margins (i.e., an
automatic return and line-feed when the end of a line is reached)
is indicated by the capability am. Hence the description of
ansi includes am. Numeric capabilities are followed by the
character ‘#’ and then a positive value. Thus
cols, which indicates the number of columns the terminal
has, gives the value ‘80’ for ansi. Values for numeric
capabilities may be specified in decimal, octal or hexadecimal,
using the C programming language conventions (e.g., 255, 0377 and
0xff or 0xFF).
Finally, string valued
capabilities, such as el (clear to end of line sequence) are
given by the two-character code, an ‘=’, and then a
string ending at the next following ‘,’.
A number of escape
sequences are provided in the string valued capabilities for easy
encoding of characters there. Both \E and \e map to
an ESCAPE character, ^x maps to a control-x
for any appropriate x, and the sequences \n \l \r \t \b \f
\s give a newline, line-feed, return, tab, backspace,
form-feed, and space. Other escapes include \^ for ^,
\\ for \, \, for comma, \: for
:, and \0 for null. (\0 will produce \200,
which does not terminate a string but behaves as a null character
on most terminals, providing CS7 is specified. See stty(1).)
Finally, characters may be given as three octal digits after a
\.
A delay in milliseconds
may appear anywhere in a string capability, enclosed in $<..>
brackets, as in el=\EK$<5>, and padding characters are
supplied by tputs to provide this delay. The delay must be a
number with at most one decimal place of precision; it may be
followed by suffixes ‘*’ or ’/’ or both. A
‘*’ indicates that the padding required is proportional
to the number of lines affected by the operation, and the amount
given is the per-affected-unit padding required. (In the case of
insert character, the factor is still the number of lines
affected.) Normally, padding is advisory if the device has the
xon capability; it is used for cost computation but does not
trigger delays. A ‘/’ suffix indicates that the padding
is mandatory and forces a delay of the given number of milliseconds
even on devices for which xon is present to indicate flow
control.
Sometimes individual
capabilities must be commented out. To do this, put a period before
the capability name. For example, see the second ind in the
example above.
Fetching Compiled
Descriptions
If the environment variable TERMINFO is set, it is interpreted as
the pathname of a directory containing the compiled description you
are working on. Only that directory is searched.
If TERMINFO is not set,
the ncurses version of the terminfo reader code will instead
look in the directory $HOME/.terminfo for a compiled
description. If it fails to find one there, and the environment
variable TERMINFO_DIRS is set, it will interpret the contents of
that variable as a list of colon- separated directories to be
searched (an empty entry is interpreted as a command to search
/usr/share/misc/terminfo). If no description is found in any
of the TERMINFO_DIRS directories, the fetch fails.
If neither TERMINFO nor
TERMINFO_DIRS is set, the last place tried will be the system
terminfo directory, /usr/share/misc/terminfo.
(Neither the
$HOME/.terminfo lookups nor TERMINFO_DIRS extensions are
supported under stock System V terminfo/curses.)
Preparing
Descriptions
We now outline how to prepare descriptions of terminals. The most
effective way to prepare a terminal description is by imitating the
description of a similar terminal in terminfo and to build
up a description gradually, using partial descriptions with
vi or some other screen-oriented program to check that they
are correct. Be aware that a very unusual terminal may expose
deficiencies in the ability of the terminfo file to describe
it or bugs in the screen-handling code of the test program.
To get the padding for
insert line right (if the terminal manufacturer did not document
it) a severe test is to edit a large file at 9600 baud, delete 16
or so lines from the middle of the screen, then hit the
‘u’ key several times quickly. If the terminal messes
up, more padding is usually needed. A similar test can be used for
insert character.
Basic
Capabilities
The number of columns on each line for the terminal is given by the
cols numeric capability. If the terminal is a
CRT , then the number of lines on the screen is
given by the lines capability. If the terminal wraps around
to the beginning of the next line when it reaches the right margin,
then it should have the am capability. If the terminal can
clear its screen, leaving the cursor in the home position, then
this is given by the clear string capability. If the
terminal overstrikes (rather than clearing a position when a
character is struck over) then it should have the os
capability. If the terminal is a printing terminal, with no soft
copy unit, give it both hc and os. (os applies
to storage scope terminals, such as TEKTRONIX 4010
series, as well as hard copy and APL terminals.) If there is a code
to move the cursor to the left edge of the current row, give this
as cr. (Normally this will be carriage return, control M.)
If there is a code to produce an audible signal (bell, beep, etc)
give this as bel.
If there is a code to
move the cursor one position to the left (such as backspace) that
capability should be given as cub1. Similarly, codes to move
to the right, up, and down should be given as cuf1,
cuu1, and cud1. These local cursor motions should not
alter the text they pass over, for example, you would not normally
use ‘cuf1= ’ because the space would erase
the character moved over.
A very important point
here is that the local cursor motions encoded in terminfo
are undefined at the left and top edges of a CRT
terminal. Programs should never attempt to backspace around the
left edge, unless bw is given, and never attempt to go up
locally off the top. In order to scroll text up, a program will go
to the bottom left corner of the screen and send the ind
(index) string.
To scroll text down, a
program goes to the top left corner of the screen and sends the
ri (reverse index) string. The strings ind and
ri are undefined when not on their respective corners of the
screen.
Parameterized versions
of the scrolling sequences are indn and rin which
have the same semantics as ind and ri except that
they take one parameter, and scroll that many lines. They are also
undefined except at the appropriate edge of the screen.
The am
capability tells whether the cursor sticks at the right edge of the
screen when text is output, but this does not necessarily apply to
a cuf1 from the last column. The only local motion which is
defined from the left edge is if bw is given, then a
cub1 from the left edge will move to the right edge of the
previous row. If bw is not given, the effect is undefined.
This is useful for drawing a box around the edge of the screen, for
example. If the terminal has switch selectable automatic margins,
the terminfo file usually assumes that this is on; i.e.,
am. If the terminal has a command which moves to the first
column of the next line, that command can be given as nel
(newline). It does not matter if the command clears the remainder
of the current line, so if the terminal has no cr and
lf it may still be possible to craft a working nel
out of one or both of them.
These capabilities
suffice to describe hard-copy and “glass-tty”
terminals. Thus the model 33 teletype is described as
33|tty33|tty|model 33 teletype,
bel=^G, cols#72, cr=^M, cud1=^J, hc, ind=^J, os,
while the Lear Siegler ADM-3 is described as
adm3|3|lsi adm3,
am, bel=^G, clear=^Z, cols#80, cr=^M, cub1=^H, cud1=^J,
ind=^J, lines#24,
Parameterized
Strings
Cursor addressing and other strings requiring parameters in the
terminal are described by a parameterized string capability, with
printf(3S) like escapes %x in it. For example, to
address the cursor, the cup capability is given, using two
parameters: the row and column to address to. (Rows and columns are
numbered from zero and refer to the physical screen visible to the
user, not to any unseen memory.) If the terminal has memory
relative cursor addressing, that can be indicated by
mrcup.
The parameter mechanism
uses a stack and special % codes to manipulate it. Typically
a sequence will push one of the parameters onto the stack and then
print it in some format. Print (e.g., "%d") is a special case.
Other operations, including "%t" pop their operand from the stack.
It is noted that more complex operations are often necessary, e.g.,
in the sgr string.
The % encodings
have the following meanings:
%[[:]flags][width[.precision]][doxXs]
as in printf, flags are [-+#]
and space
|
%c
|
|
print pop() like %c in
printf
|
|
|
%s
|
|
print pop() like %s in
printf
|
|
%p[1-9]
push i’th parameter
%P[a-z]
set dynamic variable [a-z] to pop()
%g[a-z]
get dynamic variable [a-z] and push
it
%P[A-Z]
set static variable [a-z] to pop()
%g[A-Z]
get static variable [a-z] and push
it
The terms "static" and
"dynamic" are misleading. Historically, these are simply two
different sets of variables, whose values are not reset between
calls to tparm. However, that fact is not documented in
other implementations. Relying on it will adversely impact
portability to other implementations.
%{nn}
integer constant nn
%+ %- %* %/ %m
arithmetic (%m is mod): push(pop() op
pop())
%& %| %^
bit operations (AND, OR and
exclusive-OR): push(pop() op pop())
%= %> %<
logical operations: push(pop() op
pop())
%A, %O
logical AND and OR operations (for
conditionals)
%! %~
unary operations (logical and bit
complement): push(op pop())
|
%i
|
|
add 1 to first two
parameters (for ANSI terminals)
|
|
%? expr %t thenpart %e
elsepart %;
This forms an if-then-else. The %e
elsepart is optional. Usually the %? expr part pushes
a value onto the stack, and %t pops it from the stack, testing if
it is nonzero (true). If it is zero (false), control passes to the
%e (else) part.
It is possible to form
else-if’s a la Algol 68:
%? c1 %t b1 %e c2 %t b2 %e c3 %t b3 %e c4 %t b4 %e %;
where ci are
conditions, bi are bodies.
Use the -f
option of tic or infocmp to see the structure of
if-the-else’s. Some strings, e.g., sgr can be very
complicated when written on one line. The -f option splits
the string into lines with the parts indented.
Binary operations are
in postfix form with the operands in the usual order. That is, to
get x-5 one would use "%gx%{5}%-". %P and %g variables are
persistent across escape-string evaluations.
Consider the HP2645,
which, to get to row 3 and column 12, needs to be sent
\E&a12c03Y padded for 6 milliseconds. Note that the order of
the rows and columns is inverted here, and that the row and column
are printed as two digits. Thus its cup capability is
“cup=6\E&%p2%2dc%p1%2dY”.
The Microterm
ACT-IV needs the current row and column sent
preceded by a ^T, with the row and column simply encoded in
binary, “cup=^T%p1%c%p2%c”. Terminals which use
“%c” need to be able to backspace the cursor
(cub1), and to move the cursor up one line on the screen
(cuu1). This is necessary because it is not always safe to
transmit \n ^D and \r, as the system may change or
discard them. (The library routines dealing with terminfo set tty
modes so that tabs are never expanded, so \t is safe to send. This
turns out to be essential for the Ann Arbor 4080.)
A final example is the
LSI ADM -3a, which uses row and column offset by a
blank character, thus “cup=\E=%p1%’
’%+%c%p2%’ ’%+%c”. After sending
‘\E=’, this pushes the first parameter, pushes the
ASCII value for a space (32), adds them (pushing the sum on the
stack in place of the two previous values) and outputs that value
as a character. Then the same is done for the second parameter.
More complex arithmetic is possible using the stack.
Cursor
Motions
If the terminal has a fast way to home the cursor (to very upper
left corner of screen) then this can be given as home;
similarly a fast way of getting to the lower left-hand corner can
be given as ll; this may involve going up with cuu1
from the home position, but a program should never do this itself
(unless ll does) because it can make no assumption about the
effect of moving up from the home position. Note that the home
position is the same as addressing to (0,0): to the top left corner
of the screen, not of memory. (Thus, the \EH sequence on HP
terminals cannot be used for home.)
If the terminal has row
or column absolute cursor addressing, these can be given as single
parameter capabilities hpa (horizontal position absolute)
and vpa (vertical position absolute). Sometimes these are
shorter than the more general two parameter sequence (as with the
hp2645) and can be used in preference to cup. If there are
parameterized local motions (e.g., move n spaces to the
right) these can be given as cud, cub, cuf,
and cuu with a single parameter indicating how many spaces
to move. These are primarily useful if the terminal does not have
cup, such as the TEKTRONIX 4025.
If the terminal needs
to be in a special mode when running a program that uses these
capabilities, the codes to enter and exit this mode can be given as
smcup and rmcup. This arises, for example, from
terminals like the Concept with more than one page of memory. If
the terminal has only memory relative cursor addressing and not
screen relative cursor addressing, a one screen-sized window must
be fixed into the terminal for cursor addressing to work properly.
This is also used for the TEKTRONIX 4025, where
smcup sets the command character to be the one used by
terminfo. If the smcup sequence will not restore the screen
after an rmcup sequence is output (to the state prior to
outputting rmcup), specify nrrmc.
Area
Clears
If the terminal can clear from the current position to the end of
the line, leaving the cursor where it is, this should be given as
el. If the terminal can clear from the beginning of the line
to the current position inclusive, leaving the cursor where it is,
this should be given as el1. If the terminal can clear from
the current position to the end of the display, then this should be
given as ed. Ed is only defined from the first column
of a line. (Thus, it can be simulated by a request to delete a
large number of lines, if a true ed is not available.)
Insert/delete line
and vertical motions
If the terminal can open a new blank line before the line where the
cursor is, this should be given as il1; this is done only
from the first position of a line. The cursor must then appear on
the newly blank line. If the terminal can delete the line which the
cursor is on, then this should be given as dl1; this is done
only from the first position on the line to be deleted. Versions of
il1 and dl1 which take a single parameter and insert
or delete that many lines can be given as il and
dl.
If the terminal has a
settable scrolling region (like the vt100) the command to set this
can be described with the csr capability, which takes two
parameters: the top and bottom lines of the scrolling region. The
cursor position is, alas, undefined after using this command.
It is possible to get
the effect of insert or delete line using csr on a properly
chosen region; the sc and rc (save and restore
cursor) commands may be useful for ensuring that your synthesized
insert/delete string does not move the cursor. (Note that the
ncurses(3X) library does this synthesis automatically, so
you need not compose insert/delete strings for an entry with
csr).
Yet another way to
construct insert and delete might be to use a combination of index
with the memory-lock feature found on some terminals (like the
HP-700/90 series, which however also has insert/delete).
Inserting lines at the
top or bottom of the screen can also be done using ri or
ind on many terminals without a true insert/delete line, and
is often faster even on terminals with those features.
The boolean
non_dest_scroll_region should be set if each scrolling
window is effectively a view port on a screen-sized canvas. To test
for this capability, create a scrolling region in the middle of the
screen, write something to the bottom line, move the cursor to the
top of the region, and do ri followed by dl1 or
ind. If the data scrolled off the bottom of the region by
the ri re-appears, then scrolling is non-destructive. System
V and XSI Curses expect that ind, ri, indn,
and rin will simulate destructive scrolling; their
documentation cautions you not to define csr unless this is
true. This curses implementation is more liberal and will do
explicit erases after scrolling if ndstr is defined.
If the terminal has the
ability to define a window as part of memory, which all commands
affect, it should be given as the parameterized string wind.
The four parameters are the starting and ending lines in memory and
the starting and ending columns in memory, in that order.
If the terminal can
retain display memory above, then the da capability should
be given; if display memory can be retained below, then db
should be given. These indicate that deleting a line or scrolling
may bring non-blank lines up from below or that scrolling back with
ri may bring down non-blank lines.
Insert/Delete
Character
There are two basic kinds of intelligent terminals with respect to
insert/delete character which can be described using
terminfo. The most common insert/delete character operations
affect only the characters on the current line and shift characters
off the end of the line rigidly. Other terminals, such as the
Concept 100 and the Perkin Elmer Owl, make a distinction between
typed and untyped blanks on the screen, shifting upon an insert or
delete only to an untyped blank on the screen which is either
eliminated, or expanded to two untyped blanks. You can determine
the kind of terminal you have by clearing the screen and then
typing text separated by cursor motions. Type
“abc def” using local cursor
motions (not spaces) between the “abc” and the
“def”. Then position the cursor before the
“abc” and put the terminal in insert mode. If typing
characters causes the rest of the line to shift rigidly and
characters to fall off the end, then your terminal does not
distinguish between blanks and untyped positions. If the
“abc” shifts over to the “def” which then
move together around the end of the current line and onto the next
as you insert, you have the second type of terminal, and should
give the capability in, which stands for “insert
null”. While these are two logically separate attributes (one
line versus multi-line insert mode, and special treatment of
untyped spaces) we have seen no terminals whose insert mode cannot
be described with the single attribute.
Terminfo can describe
both terminals which have an insert mode, and terminals which send
a simple sequence to open a blank position on the current line.
Give as smir the sequence to get into insert mode. Give as
rmir the sequence to leave insert mode. Now give as
ich1 any sequence needed to be sent just before sending the
character to be inserted. Most terminals with a true insert mode
will not give ich1; terminals which send a sequence to open
a screen position should give it here.
If your terminal has
both, insert mode is usually preferable to ich1.
Technically, you should not give both unless the terminal actually
requires both to be used in combination. Accordingly, some
non-curses applications get confused if both are present; the
symptom is doubled characters in an update using insert. This
requirement is now rare; most ich sequences do not require
previous smir, and most smir insert modes do not require
ich1 before each character. Therefore, the new curses
actually assumes this is the case and uses either
rmir/smir or ich/ich1 as appropriate
(but not both). If you have to write an entry to be used under new
curses for a terminal old enough to need both, include the
rmir/smir sequences in ich1.
If post insert padding
is needed, give this as a number of milliseconds in ip (a
string option). Any other sequence which may need to be sent after
an insert of a single character may also be given in ip. If
your terminal needs both to be placed into an ‘insert
mode’ and a special code to precede each inserted character,
then both smir/rmir and ich1 can be given, and
both will be used. The ich capability, with one parameter,
n, will repeat the effects of ich1 n
times.
If padding is necessary
between characters typed while not in insert mode, give this as a
number of milliseconds padding in rmp.
It is occasionally
necessary to move around while in insert mode to delete characters
on the same line (e.g., if there is a tab after the insertion
position). If your terminal allows motion while in insert mode you
can give the capability mir to speed up inserting in this
case. Omitting mir will affect only speed. Some terminals
(notably Datamedia’s) must not have mir because of the
way their insert mode works.
Finally, you can
specify dch1 to delete a single character, dch with
one parameter, n, to delete n characters, and delete
mode by giving smdc and rmdc to enter and exit delete
mode (any mode the terminal needs to be placed in for dch1
to work).
A command to erase
n characters (equivalent to outputting n blanks
without moving the cursor) can be given as ech with one
parameter.
Highlighting,
Underlining, and Visible Bells
If your terminal has one or more kinds of display attributes, these
can be represented in a number of different ways. You should choose
one display form as standout mode, representing a good, high
contrast, easy-on-the-eyes, format for highlighting error messages
and other attention getters. (If you have a choice, reverse video
plus half-bright is good, or reverse video alone.) The sequences to
enter and exit standout mode are given as smso and
rmso, respectively. If the code to change into or out of
standout mode leaves one or even two blank spaces on the screen, as
the TVI 912 and Teleray 1061 do, then xmc should be given to
tell how many spaces are left.
Codes to begin
underlining and end underlining can be given as smul and
rmul respectively. If the terminal has a code to underline
the current character and move the cursor one space to the right,
such as the Microterm Mime, this can be given as uc.
Other capabilities to
enter various highlighting modes include blink (blinking)
bold (bold or extra bright) dim (dim or half-bright)
invis (blanking or invisible text) prot (protected)
rev (reverse video) sgr0 (turn off all
attribute modes) smacs (enter alternate character set mode)
and rmacs (exit alternate character set mode). Turning on
any of these modes singly may or may not turn off other modes.
If there is a sequence
to set arbitrary combinations of modes, this should be given as
sgr (set attributes), taking 9 parameters. Each parameter is
either 0 or nonzero, as the corresponding attribute is on or off.
The 9 parameters are, in order: standout, underline, reverse,
blink, dim, bold, blank, protect, alternate character set. Not all
modes need be supported by sgr, only those for which
corresponding separate attribute commands exist.
For example, the DEC
vt220 supports most of the modes:
We begin each escape
sequence by turning off any existing modes, since there is no quick
way to determine whether they are active. Standout is set up to be
the combination of reverse and bold. The vt220 terminal has a
protect mode, though it is not commonly used in sgr because it
protects characters on the screen from the host’s erasures.
The altcharset mode also is different in that it is either ^O or
^N, depending on whether it is off or on. If all modes are turned
on, the resulting sequence is \E[0;1;4;5;7;8m^N.
Some sequences are
common to different modes. For example, ;7 is output when either p1
or p3 is true, that is, if either standout or reverse modes are
turned on.
Writing out the above
sequences, along with their dependencies yields
Putting this all
together into the sgr sequence gives:
sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;
%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\016%e\017%;,
Remember that if you
specify sgr, you must also specify sgr0. Also, some implementations
rely on sgr being given if sgr0 is, Not all terminfo entries
necessarily have an sgr string, however. Many terminfo entries are
derived from termcap entries which have no sgr string. The only
drawback to adding an sgr string is that termcap also assumes that
sgr0 does not exit alternate character set mode.
Terminals with the
‘‘magic cookie’’ glitch (xmc)
deposit special ‘‘cookies’’ when they
receive mode-setting sequences, which affect the display algorithm
rather than having extra bits for each character. Some terminals,
such as the HP 2621, automatically leave standout mode when they
move to a new line or the cursor is addressed. Programs using
standout mode should exit standout mode before moving the cursor or
sending a newline, unless the msgr capability, asserting
that it is safe to move in standout mode, is present.
If the terminal has a
way of flashing the screen to indicate an error quietly (a bell
replacement) then this can be given as flash; it must not
move the cursor.
If the cursor needs to
be made more visible than normal when it is not on the bottom line
(to make, for example, a non-blinking underline into an easier to
find block or blinking underline) give this sequence as
cvvis. If there is a way to make the cursor completely
invisible, give that as civis. The capability cnorm
should be given which undoes the effects of both of these
modes.
If your terminal
correctly generates underlined characters (with no special codes
needed) even though it does not overstrike, then you should give
the capability ul. If a character overstriking another
leaves both characters on the screen, specify the capability
os. If overstrikes are erasable with a blank, then this
should be indicated by giving eo.
Keypad and Function
Keys
If the terminal has a keypad that transmits codes when the keys are
pressed, this information can be given. Note that it is not
possible to handle terminals where the keypad only works in local
(this applies, for example, to the unshifted HP 2621 keys). If the
keypad can be set to transmit or not transmit, give these codes as
smkx and rmkx. Otherwise the keypad is assumed to
always transmit. The codes sent by the left arrow, right arrow, up
arrow, down arrow, and home keys can be given as kcub1, kcuf1,
kcuu1, kcud1, and khome respectively. If there are
function keys such as f0, f1, ..., f10, the codes they send can be
given as kf0, kf1, ..., kf10. If these keys have labels
other than the default f0 through f10, the labels can be given as
lf0, lf1, ..., lf10. The codes transmitted by certain other
special keys can be given: kll (home down), kbs
(backspace), ktbc (clear all tabs), kctab (clear the
tab stop in this column), kclr (clear screen or erase key),
kdch1 (delete character), kdl1 (delete line),
krmir (exit insert mode), kel (clear to end of line),
ked (clear to end of screen), kich1 (insert character
or enter insert mode), kil1 (insert line), knp (next
page), kpp (previous page), kind (scroll
forward/down), kri (scroll backward/up), khts (set a
tab stop in this column). In addition, if the keypad has a 3 by 3
array of keys including the four arrow keys, the other five keys
can be given as ka1, ka3, kb2, kc1, and
kc3. These keys are useful when the effects of a 3 by 3
directional pad are needed.
Strings to program
function keys can be given as pfkey, pfloc, and
pfx. A string to program screen labels should be specified
as pln. Each of these strings takes two parameters: the
function key number to program (from 0 to 10) and the string to
program it with. Function key numbers out of this range may program
undefined keys in a terminal dependent manner. The difference
between the capabilities is that pfkey causes pressing the
given key to be the same as the user typing the given string;
pfloc causes the string to be executed by the terminal in
local; and pfx causes the string to be transmitted to the
computer.
The capabilities
nlab, lw and lh define the number of
programmable screen labels and their width and height. If there are
commands to turn the labels on and off, give them in smln
and rmln. smln is normally output after one or more
pln sequences to make sure that the change becomes visible.
Tabs and
Initialization
If the terminal has hardware tabs, the command to advance to the
next tab stop can be given as ht (usually control I). A
‘‘back-tab’’ command which moves leftward
to the preceding tab stop can be given as cbt. By
convention, if the teletype modes indicate that tabs are being
expanded by the computer rather than being sent to the terminal,
programs should not use ht or cbt even if they are
present, since the user may not have the tab stops properly set. If
the terminal has hardware tabs which are initially set every
n spaces when the terminal is powered up, the numeric
parameter it is given, showing the number of spaces the tabs
are set to. This is normally used by the tset command to
determine whether to set the mode for hardware tab expansion, and
whether to set the tab stops. If the terminal has tab stops that
can be saved in non-volatile memory, the terminfo description can
assume that they are properly set.
Other capabilities
include is1, is2, and is3, initialization
strings for the terminal, iprog, the path name of a program
to be run to initialize the terminal, and if, the name of a
file containing long initialization strings. These strings are
expected to set the terminal into modes consistent with the rest of
the terminfo description. They are normally sent to the terminal,
by the init option of the tput program, each time the
user logs in. They will be printed in the following order:
run the program
iprog
set the margins using
mgc, smgl and
smgr
set tabs using
tbc and hts
print the file
if
and finally
output is3.
Most initialization is
done with is2. Special terminal modes can be set up without
duplicating strings by putting the common sequences in is2
and special cases in is1 and is3.
A set of sequences that
does a harder reset from a totally unknown state can be given as
rs1, rs2, rf and rs3, analogous to
is1 , is2 , if and is3 respectively. These strings
are output by the reset program, which is used when the
terminal gets into a wedged state. Commands are normally placed in
rs1, rs2 rs3 and rf only if they produce
annoying effects on the screen and are not necessary when logging
in. For example, the command to set the vt100 into 80-column mode
would normally be part of is2, but it causes an annoying
glitch of the screen and is not normally needed since the terminal
is usually already in 80 column mode.
The reset
program writes strings including iprog, etc., in the same
order as the init program, using rs1, etc., instead
of is1, etc. If any of rs1, rs2, rs3,
or rf reset capability strings are missing, the reset
program falls back upon the corresponding initialization capability
string.
If there are commands
to set and clear tab stops, they can be given as tbc (clear
all tab stops) and hts (set a tab stop in the current column
of every row). If a more complex sequence is needed to set the tabs
than can be described by this, the sequence can be placed in
is2 or if.
Delays and
Padding
Many older and slower terminals do not support either XON/XOFF or
DTR handshaking, including hard copy terminals and some very
archaic CRTs (including, for example, DEC VT100s). These may
require padding characters after certain cursor motions and screen
changes.
If the terminal uses
xon/xoff handshaking for flow control (that is, it automatically
emits ^S back to the host when its input buffers are close to
full), set xon. This capability suppresses the emission of
padding. You can also set it for memory-mapped console devices
effectively that do not have a speed limit. Padding information
should still be included so that routines can make better decisions
about relative costs, but actual pad characters will not be
transmitted.
If pb (padding
baud rate) is given, padding is suppressed at baud rates below the
value of pb. If the entry has no padding baud rate, then
whether padding is emitted or not is completely controlled by
xon.
If the terminal
requires other than a null (zero) character as a pad, then this can
be given as pad. Only the first character of the pad
string is used.
Status
Lines
Some terminals have an extra ‘status line’ which is not
normally used by software (and thus not counted in the
terminal’s lines capability).
The simplest case is a
status line which is cursor-addressable but not part of the main
scrolling region on the screen; the Heathkit H19 has a status line
of this kind, as would a 24-line VT100 with a 23-line scrolling
region set up on initialization. This situation is indicated by the
hs capability.
Some terminals with
status lines need special sequences to access the status line.
These may be expressed as a string with single parameter tsl
which takes the cursor to a given zero-origin column on the status
line. The capability fsl must return to the main-screen
cursor positions before the last tsl. You may need to embed
the string values of sc (save cursor) and rc (restore
cursor) in tsl and fsl to accomplish this.
The status line is
normally assumed to be the same width as the width of the terminal.
If this is untrue, you can specify it with the numeric capability
wsl.
A command to erase or
blank the status line may be specified as dsl.
The boolean capability
eslok specifies that escape sequences, tabs, etc., work
ordinarily in the status line.
The ncurses
implementation does not yet use any of these capabilities. They are
documented here in case they ever become important.
Line
Graphics
Many terminals have alternate character sets useful for
forms-drawing. Terminfo and curses build in support for the
drawing characters supported by the VT100, with some characters
from the AT&T 4410v1 added. This alternate character set may be
specified by the acsc capability.
The best way to define
a new device’s graphics set is to add a column to a copy of
this table for your terminal, giving the character which (when
emitted between smacs/rmacs switches) will be
rendered as the corresponding graphic. Then read off the VT100/your
terminal character pairs right to left in sequence; these become
the ACSC string.
Color
Handling
Most color terminals are either ‘Tektronix-like’ or
‘HP-like’. Tektronix-like terminals have a predefined
set of N colors (where N usually 8), and can set character-cell
foreground and background characters independently, mixing them
into N * N color-pairs. On HP-like terminals, the use must set each
color pair up separately (foreground and background are not
independently settable). Up to M color-pairs may be set up from 2*M
different colors. ANSI-compatible terminals are Tektronix-like.
Some basic color
capabilities are independent of the color method. The numeric
capabilities colors and pairs specify the maximum
numbers of colors and color-pairs that can be displayed
simultaneously. The op (original pair) string resets
foreground and background colors to their default values for the
terminal. The oc string resets all colors or color-pairs to
their default values for the terminal. Some terminals (including
many PC terminal emulators) erase screen areas with the current
background color rather than the power-up default background; these
should have the boolean capability bce.
To change the current
foreground or background color on a Tektronix-type terminal, use
setaf (set ANSI foreground) and setab (set ANSI
background) or setf (set foreground) and setb (set
background). These take one parameter, the color number. The SVr4
documentation describes only setaf/setab; the XPG4
draft says that "If the terminal supports ANSI escape sequences to
set background and foreground, they should be coded as setaf
and setab, respectively. If the terminal supports other
escape sequences to set background and foreground, they should be
coded as setf and setb, respectively. The
vidputs() function and the refresh functions use
setaf and setab if they are defined."
The
setaf/setab and setf/setb capabilities
take a single numeric argument each. Argument values 0-7 of
setaf/setab are portably defined as follows (the
middle column is the symbolic #define available in the header for
the curses or ncurses libraries). The terminal
hardware is free to map these as it likes, but the RGB values
indicate normal locations in color space.
The argument values of
setf/setb historically correspond to a different
mapping, i.e.,
It is important
to not confuse the two sets of color capabilities; otherwise
red/blue will be interchanged on the display.
On an HP-like terminal,
use scp with a color-pair number parameter to set which
color pair is current.
On a Tektronix-like
terminal, the capability ccc may be present to indicate that
colors can be modified. If so, the initc capability will
take a color number (0 to colors - 1)and three more
parameters which describe the color. These three parameters default
to being interpreted as RGB (Red, Green, Blue) values. If the
boolean capability hls is present, they are instead as HLS
(Hue, Lightness, Saturation) indices. The ranges are
terminal-dependent.
On an HP-like terminal,
initp may give a capability for changing a color-pair value.
It will take seven parameters; a color-pair number (0 to
max_pairs - 1), and two triples describing first background
and then foreground colors. These parameters must be (Red, Green,
Blue) or (Hue, Lightness, Saturation) depending on hls.
On some color
terminals, colors collide with highlights. You can register these
collisions with the ncv capability. This is a bit-mask of
attributes not to be used when colors are enabled. The
correspondence with the attributes understood by curses is
as follows:
For example, on many
IBM PC consoles, the underline attribute collides with the
foreground color blue and is not available in color mode. These
should have an ncv capability of 2.
SVr4 curses does
nothing with ncv, ncurses recognizes it and optimizes the
output in favor of colors.
Miscellaneous
If the terminal requires other than a null (zero) character as a
pad, then this can be given as pad. Only the first character of the
pad string is used. If the terminal does not have a pad character,
specify npc. Note that ncurses implements the termcap-compatible
PC variable; though the application may set this value to
something other than a null, ncurses will test npc first and
use napms if the terminal has no pad character.
If the terminal can
move up or down half a line, this can be indicated with hu
(half-line up) and hd (half-line down). This is primarily
useful for superscripts and subscripts on hard-copy terminals. If a
hard-copy terminal can eject to the next page (form feed), give
this as ff (usually control L).
If there is a command
to repeat a given character a given number of times (to save time
transmitting a large number of identical characters) this can be
indicated with the parameterized string rep. The first
parameter is the character to be repeated and the second is the
number of times to repeat it. Thus, tparm(repeat_char,
’x’, 10) is the same as ‘xxxxxxxxxx’.
If the terminal has a
settable command character, such as the TEKTRONIX
4025, this can be indicated with cmdch. A prototype command
character is chosen which is used in all capabilities. This
character is given in the cmdch capability to identify it.
The following convention is supported on some UNIX systems: The
environment is to be searched for a CC variable, and if
found, all occurrences of the prototype character are replaced with
the character in the environment variable.
Terminal descriptions
that do not represent a specific kind of known terminal, such as
switch, dialup, patch, and network,
should include the gn (generic) capability so that programs
can complain that they do not know how to talk to the terminal.
(This capability does not apply to virtual terminal
descriptions for which the escape sequences are known.)
If the terminal has a
‘‘meta key’’ which acts as a shift key,
setting the 8th bit of any character transmitted, this fact can be
indicated with km. Otherwise, software will assume that the
8th bit is parity and it will usually be cleared. If strings exist
to turn this ‘‘meta mode’’ on and off, they
can be given as smm and rmm.
If the terminal has
more lines of memory than will fit on the screen at once, the
number of lines of memory can be indicated with lm. A value
of lm#0 indicates that the number of lines is not fixed, but
that there is still more memory than fits on the screen.
If the terminal is one
of those supported by the UNIX virtual terminal
protocol, the terminal number can be given as vt.
Media copy strings
which control an auxiliary printer connected to the terminal can be
given as mc0: print the contents of the screen, mc4:
turn off the printer, and mc5: turn on the printer. When the
printer is on, all text sent to the terminal will be sent to the
printer. It is undefined whether the text is also displayed on the
terminal screen when the printer is on. A variation mc5p
takes one parameter, and leaves the printer on for as many
characters as the value of the parameter, then turns the printer
off. The parameter should not exceed 255. All text, including
mc4, is transparently passed to the printer while an
mc5p is in effect.
Glitches and
Braindamage
Hazeltine terminals, which do not allow ‘~’ characters
to be displayed should indicate hz.
Terminals which ignore
a line-feed immediately after an am wrap, such as the
Concept and vt100, should indicate xenl.
If el is
required to get rid of standout (instead of merely writing normal
text on top of it), xhp should be given.
Teleray terminals,
where tabs turn all characters moved over to blanks, should
indicate xt (destructive tabs). Note: the variable
indicating this is now ‘dest_tabs_magic_smso’; in older
versions, it was teleray_glitch. This glitch is also taken to mean
that it is not possible to position the cursor on top of a
‘‘magic cookie’’, that to erase standout
mode it is instead necessary to use delete and insert line. The
ncurses implementation ignores this glitch.
The Beehive Superbee,
which is unable to correctly transmit the escape or control C
characters, has xsb, indicating that the f1 key is used for
escape and f2 for control C. (Only certain Superbees have this
problem, depending on the ROM.) Note that in older terminfo
versions, this capability was called ‘beehive_glitch’;
it is now ‘no_esc_ctl_c’.
Other specific terminal
problems may be corrected by adding more capabilities of the form
xx.
Similar
Terminals
If there are two very similar terminals, one (the variant) can be
defined as being just like the other (the base) with certain
exceptions. In the definition of the variant, the string capability
use can be given with the name of the base terminal. The
capabilities given before use override those in the base
type named by use. If there are multiple use
capabilities, they are merged in reverse order. That is, the
rightmost use reference is processed first, then the one to
its left, and so forth. Capabilities given explicitly in the entry
override those brought in by use references.
A capability can be
canceled by placing xx@ to the left of the use reference
that imports it, where xx is the capability. For example,
the entry
2621-nl, smkx@, rmkx@,
use=2621,
defines a 2621-nl that
does not have the smkx or rmkx capabilities, and
hence does not turn on the function key labels when in visual mode.
This is useful for different modes for a terminal, or for different
user preferences.
Pitfalls of Long
Entries
Long terminfo entries are unlikely to be a problem; to date, no
entry has even approached terminfo’s 4096-byte string-table
maximum. Unfortunately, the termcap translations are much more
strictly limited (to 1023 bytes), thus termcap translations of long
terminfo entries can cause problems.
The man pages for
4.3BSD and older versions of tgetent() instruct the user to
allocate a 1024-byte buffer for the termcap entry. The entry gets
null-terminated by the termcap library, so that makes the maximum
safe length for a termcap entry 1k-1 (1023) bytes. Depending on
what the application and the termcap library being used does, and
where in the termcap file the terminal type that tgetent()
is searching for is, several bad things can happen.
Some termcap libraries
print a warning message or exit if they find an entry that’s
longer than 1023 bytes; others do not; others truncate the entries
to 1023 bytes. Some application programs allocate more than the
recommended 1K for the termcap entry; others do not.
Each termcap entry has
two important sizes associated with it: before "tc" expansion, and
after "tc" expansion. "tc" is the capability that tacks on another
termcap entry to the end of the current one, to add on its
capabilities. If a termcap entry does not use the "tc" capability,
then of course the two lengths are the same.
The "before tc
expansion" length is the most important one, because it affects
more than just users of that particular terminal. This is the
length of the entry as it exists in /etc/termcap, minus the
backslash-newline pairs, which tgetent() strips out while
reading it. Some termcap libraries strip off the final newline, too
(GNU termcap does not). Now suppose:
|
*
|
|
a termcap entry before
expansion is more than 1023 bytes long,
|
|
*
|
|
and the application has
only allocated a 1k buffer,
|
|
*
|
|
and the termcap library
(like the one in BSD/OS 1.1 and GNU) reads the whole entry into the
buffer, no matter what its length, to see if it’s the entry
it wants,
|
|
*
|
|
and tgetent() is
searching for a terminal type that either is the long entry,
appears in the termcap file after the long entry, or does not
appear in the file at all (so that tgetent() has to search
the whole termcap file).
|
Then tgetent()
will overwrite memory, perhaps its stack, and probably core dump
the program. Programs like telnet are particularly vulnerable;
modern telnets pass along values like the terminal type
automatically. The results are almost as undesirable with a termcap
library, like SunOS 4.1.3 and Ultrix 4.4, that prints warning
messages when it reads an overly long termcap entry. If a termcap
library truncates long entries, like OSF/1 3.0, it is immune to
dying here but will return incorrect data for the terminal.
The "after tc
expansion" length will have a similar effect to the above, but only
for people who actually set TERM to that terminal type, since
tgetent() only does "tc" expansion once it’s found the
terminal type it was looking for, not while searching.
In summary, a termcap
entry that is longer than 1023 bytes can cause, on various
combinations of termcap libraries and applications, a core dump,
warnings, or incorrect operation. If it’s too long even
before "tc" expansion, it will have this effect even for users of
some other terminal types and users whose TERM variable does not
have a termcap entry.
When in -C (translate
to termcap) mode, the ncurses implementation of
tic(1) issues warning messages when the pre-tc length of a
termcap translation is too long. The -c (check) option also checks
resolved (after tc expansion) lengths.
Binary
Compatibility
It is not wise to count on portability of binary terminfo entries
between commercial UNIX versions. The problem is that there are at
least two versions of terminfo (under HP-UX and AIX) which diverged
from System V terminfo after SVr1, and have added extension
capabilities to the string table that (in the binary format)
collide with System V and XSI Curses extensions.
EXTENSIONS
Some SVr4 curses
implementations, and all previous to SVr4, do not interpret the %A
and %O operators in parameter strings.
SVr4/XPG4 do not
specify whether msgr licenses movement while in an
alternate-character-set mode (such modes may, among other things,
map CR and NL to characters that do not trigger local motions). The
ncurses implementation ignores msgr in
ALTCHARSET mode. This raises the possibility that an XPG4
implementation making the opposite interpretation may need terminfo
entries made for ncurses to have msgr turned off.
The ncurses
library handles insert-character and insert-character modes in a
slightly non-standard way to get better update efficiency. See the
Insert/Delete Character subsection above.
The parameter
substitutions for set_clock and display_clock are not
documented in SVr4 or the XSI Curses standard. They are deduced
from the documentation for the AT&T 505 terminal.
Be careful assigning
the kmous capability. The ncurses wants to interpret
it as KEY_MOUSE, for use by terminals and emulators like
xterm that can return mouse-tracking information in the
keyboard-input stream.
Different commercial
ports of terminfo and curses support different subsets of the XSI
Curses standard and (in some cases) different extension sets. Here
is a summary, accurate as of October 1995:
SVR4, Solaris,
ncurses -- These support all SVr4 capabilities.
SGI -- Supports
the SVr4 set, adds one undocumented extended string capability
(set_pglen).
SVr1, Ultrix --
These support a restricted subset of terminfo capabilities. The
booleans end with xon_xoff; the numerics with
width_status_line; and the strings with prtr_non.
HP/UX --
Supports the SVr1 subset, plus the SVr[234] numerics
num_labels, label_height, label_width, plus
function keys 11 through 63, plus plab_norm,
label_on, and label_off, plus some incompatible
extensions in the string table.
AIX -- Supports
the SVr1 subset, plus function keys 11 through 63, plus a number of
incompatible string table extensions.
OSF -- Supports
both the SVr4 set and the AIX extensions.
FILES
/usr/share/misc/terminfo/?/*
files containing terminal
descriptions
SEE ALSO
tic(1M),
infocmp(1M), curses(3X), printf(3S),
term(5).
AUTHORS
Zeyd M. Ben-Halim, Eric
S. Raymond, Thomas E. Dickey. Based on pcurses by Pavel Curtis.
|