View Source: terminfo(5) - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
Man, is this one going to be a bitch to clean up.

!!NAME

terminfo - terminal capability data base

!!SYNOPSIS

/usr/share/terminfo/*/*

!!DESCRIPTION

''Terminfo'' is a data base describing terminals, used by
screen-oriented programs such as nvi(1),
[Rogue] and libraries such as __curses__(3X).
''Terminfo'' describes terminals by giving a set of
capabilities which they have, by specifying how to perform
screen operations, and by specifying padding requirements
and initialization sequences.


Entries in ''terminfo'' consist of a sequence of `,'
separated fields (embedded commas may be escaped with a
backslash or notated as 072). White space after the `,'
separator is ignored. The first entry for each terminal
gives the names which are known for the terminal, separated
by `|' characters. The first name given is the most common
abbreviation for the terminal, the last name given should be
a long name fully identifying the terminal, and all others
are understood as synonyms for the terminal name. All names
but the last should be in lower case and contain no blanks;
the last name may well contain upper case and blanks for
readability.


Terminal names (except for the last, verbose entry) should
be chosen using the following conventions. The particular
piece of hardware making up the terminal should have a root
name, thus ``hp2621''. This name should not contain hyphens.
Modes that the hardware can be in, or user preferences,
should be indicated by appending a hyphen and a mode suffix.
Thus, a vt100 in 132 column mode would be vt100-w. The
following suffixes should be used where
possible:


For more on terminal naming conventions, see the __term(7)__ manual page.


__Capabilities__


The following is a complete table of the capabilities
included in a terminfo description block and available to
terminfo-using code. In each line of the
table,


The __variable__ is the name by which the
programmer (at the terminfo level) accesses the
capability.


The __capname__ is the short name used in the text
of the database, and is used by a person updating the
database. Whenever possible, capnames are chosen to be the
same as or similar to the ANSI X3.64-1979 standard (now
superseded by ECMA-48, which uses identical or very similar
names). Semantics are also intended to match those of the
specification.


The termcap code is the old __termcap__
capability name (some capabilities are new, and have names
which termcap did not originate).


Capability names have no hard length limit, but an informal
limit of 5 characters has been adopted to keep them short
and to allow the tabs in the source file __Caps__ to line
up nicely.


Finally, the description field attempts to convey the
semantics of the capability. You may find some codes in the
description field:


(P)


indicates that padding may be specified


#[[1-9]


in the description field indicates that the string is passed
through tparm with parms as given (#''i'').


(P*)


indicates that padding may vary in proportion to the number
of lines affected


(#''i'')


indicates the ''i''th parameter.


These are the boolean capabilities:


These are the numeric capabilities:


The following numeric capabilities are present in the SVr4.0 term structure, but are not yet documented in the man page. They came in with SVr4's printer support.


These are the string capabilities:


The following string capabilities are present in the SVr4.0 term structure, but were originally not documented in the man page.


The XSI Curses standard added these. They are some post-4.1 versions of System V curses, e.g., Solaris 2.5 and IRIX 6.x. The __ncurses__ termcap names for them are invented; according to the XSI Curses standard, they have no termcap names. If your compiled terminfo entries use these, they may not be binary-compatible with System V terminfo entries after SVr4.1; beware!


__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=rE[[S,
op=E[[37;40m, rep=%p1%cE[[%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 $
el__=EK$
__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/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/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. Often more complex operations are
necessary.


The __%__ encodings have the following
meanings:


     %%        outputs `%'
%''[[[['':'']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 parm
%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
%'''c'''      char constant ''c
''     %{''nn''}     integer constant ''nn
''     %l        push strlen(pop)
%+ %- %* %/ %m
arithmetic (%m is mod): push(pop() op pop())
%
''               ci are conditions, bi are bodies.
Binary operations are in postfix form with the operands in the usual order. That is, to get x-5 one would use


Consider the HP2645, which, to get to row 3 and column 12,
needs to be sent E
cup__ capability is
``cup=6E__


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%t016%e017%;,
Remember that if you specify sgr, you must also specify sgr0.


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__; output
__is1__; __is2__; 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 pair of sequences that does
a harder reset from a totally unknown state can be
analogously given as __rs1__, __rs2__, __rf__, and
__rs3__, analogous to __is2__ and __if__. 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.


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 don't 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
don't 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
__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
__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 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.


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 __x__''x''.


__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 4K string-table
maximum. Unfortunately, the termcap translations are much
more strictly limited (to 1K), 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 1K 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
don't; others truncate the entries to 1023 bytes. Some
application programs allocate more than the recommended 1K
for the termcap entry; others don't.


Each termcap entry has two important sizes associated with
it: before


The


*


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 doesn't 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


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


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, don't 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 don't 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__


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/terminfo/?/*


files containing terminal descriptions
!!SEE ALSO


__tic__(1M), __curses__(3X), __[printf(3)]__,
term(5).
!!AUTHORS


Zeyd M. Ben-Halim, Eric S. Raymond, Thomas E. Dickey. Based
on pcurses by Pavel Curtis.
----
15 pages link to terminfo(5):
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.
Last edited on Tuesday, October 7, 2003 7:21:46 pm by CraigBox
Edit PageHistory Diff Info LikePages