|
|
|
|
|
|
|
|
|
For more on terminal naming conventions, see the
term(7) manual page.
|
|
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 ith 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! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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/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.)
|
|
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.
|
|
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,
|
|
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() gives %c
|
|
%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())
|
|
%& %| %^
|
bit operations: push(pop() op pop())
|
|
%= %> %<
|
logical operations: push(pop() op
pop())
|
|
%A, %O
|
logical and & or operations (for
conditionals)
|
|
%! %~
|
unary operations push(op pop())
|
|
%i
|
add 1 to first two parms (for ANSI
terminals)
|
|
%? expr %t thenpart %e elsepart %;
|
|
|
|
if-then-else, %e elsepart is
optional.
|
|
|
else-if’s are possible a la Algol
68:
|
|
|
%? c1 %t b1 %e c2 %t b2 %e c3 %t b3 %e c4 %t b4
%e %;
|
|
|
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
"%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.
|
|
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.
|
|
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.
|
|
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 vs.
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.
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.
|
|
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.
|
|
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,
smgland 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.
|
|
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.
|
|
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.
|
|
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.
|
|
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 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.
|
|
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.
|
|
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.
|
|
If there are two very similar terminals, one can be
defined as being just like the other with certain
exceptions. The string capability use can be given
with the name of the similar terminal. The capabilities
given before use override those in the terminal type
invoked by use. A capability can be canceled by
placing xx@ to the left of the capability definition,
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.
|
|
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 "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
doesn’t 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 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 "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.
|
|
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 in
order 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/terminfo/?/*
|
|
files containing terminal descriptions
|
SEE ALSO
|
tic(1M), curses(3X), printf(3S),
term(5).
|
AUTHORS
|
Zeyd M. Ben-Halim, Eric S. Raymond, Thomas E. Dickey.
Based on pcurses by Pavel Curtis.
|
copyright 1998-2007, devdaily.com, all rights reserved.
devdaily.com, an alvin j. alexander production.
| | |