terminfo.tail

ncurses 库 可能有用酒用 没用就算了 我觉得还可以用

.PP
The argument values of \fBsetf\fR/\fBsetb\fR historically correspond to
a different mapping, i.e.,
.TS H
center;
l c c c
l l n l.
\fBColor	#define 	Value	RGB\fR
black	\fBCOLOR_BLACK\fR	0	0, 0, 0
blue	\fBCOLOR_BLUE\fR	1	0,0,max
green	\fBCOLOR_GREEN\fR	2	0,max,0
cyan	\fBCOLOR_CYAN\fR	3	0,max,max
red	\fBCOLOR_RED\ \fR	4	max,0,0
magenta	\fBCOLOR_MAGENTA\fR	5	max,0,max
yellow	\fBCOLOR_YELLOW\fR	6	max,max,0
white	\fBCOLOR_WHITE\fR	7	max,max,max
.TE
It is important to not confuse the two sets of color capabilities;
otherwise red/blue will be interchanged on the display.
.PP
On an HP-like terminal, use \fBscp\fR with a color-pair number parameter to set
which color pair is current.
.PP
On a Tektronix-like terminal, the capability \fBccc\fR may be present to
indicate that colors can be modified.
If so, the \fBinitc\fR capability will
take a color number (0 to \fBcolors\fR - 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 \fBhls\fR is present,
they are instead as HLS (Hue, Lightness, Saturation) indices.
The ranges are
terminal-dependent.
.PP
On an HP-like terminal, \fBinitp\fR may give a capability for changing a
color-pair value.
It will take seven parameters; a color-pair number (0 to
\fBmax_pairs\fR - 1), and two triples describing first background and then
foreground colors.
These parameters must be (Red, Green, Blue) or
(Hue, Lightness, Saturation) depending on \fBhls\fR.
.PP
On some color terminals, colors collide with highlights.
You can register
these collisions with the \fBncv\fR capability.
This is a bit-mask of
attributes not to be used when colors are enabled.
The correspondence with the
attributes understood by \fBcurses\fR is as follows:
.PP
.TS
center;
l c c
lw25 lw2 lw10.
\fBAttribute	Bit	Decimal\fR
A_STANDOUT	0	1
A_UNDERLINE	1	2
A_REVERSE	2	4
A_BLINK   	3	8
A_DIM      	4	16
A_BOLD    	5	32
A_INVIS   	6	64
A_PROTECT	7	128
A_ALTCHARSET	8	256
.TE
.PP
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 \fBncv\fR capability of 2.
.PP
SVr4 curses does nothing with \fBncv\fR, ncurses recognizes it and optimizes
the output in favor of colors.
.PP
.SS 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 \fBPC\fR variable;
though the application may set this value to something other than
a null, ncurses will test \fBnpc\fR first and use napms if the terminal
has no pad character.
.PP
If the terminal can move up or down half a line,
this can be indicated with
.B hu
(half-line up)
and
.B 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
.B ff
(usually control L).
.PP
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
.BR 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'.
.PP
If the terminal has a settable command character, such as the \s-1TEKTRONIX\s+1 4025,
this can be indicated with
.BR cmdch .
A prototype command character is chosen which is used in all capabilities.
This character is given in the
.B cmdch
capability to identify it.
The following convention is supported on some UNIX systems:
The environment is to be searched for a
.B CC
variable, and if found, all
occurrences of the prototype character are replaced with the character
in the environment variable.
.PP
Terminal descriptions that do not represent a specific kind of known
terminal, such as
.IR switch ,
.IR dialup ,
.IR patch ,
and
.IR network ,
should include the
.B 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
.I virtual
terminal descriptions for which the escape sequences are known.)
.PP
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
.BR 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
.B smm
and
.BR rmm .
.PP
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
.BR lm .
A value of
.BR lm #0
indicates that the number of lines is not fixed,
but that there is still more memory than fits on the screen.
.PP
If the terminal is one of those supported by the \s-1UNIX\s+1 virtual
terminal protocol, the terminal number can be given as
.BR vt .
.PP
Media copy
strings which control an auxiliary printer connected to the terminal
can be given as
.BR mc0 :
print the contents of the screen,
.BR mc4 :
turn off the printer, and
.BR 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
.B 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
.BR mc4 ,
is transparently passed to the printer while an
.B mc5p
is in effect.
.PP
.SS Glitches and Braindamage
.PP
Hazeltine terminals, which do not allow `~' characters to be displayed should
indicate \fBhz\fR.
.PP
Terminals which ignore a line-feed immediately after an \fBam\fR wrap,
such as the Concept and vt100,
should indicate \fBxenl\fR.
.PP
If
.B el
is required to get rid of standout
(instead of merely writing normal text on top of it),
\fBxhp\fP should be given.
.PP
Teleray terminals, where tabs turn all characters moved over to blanks,
should indicate \fBxt\fR (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.
.PP
The Beehive Superbee, which is unable to correctly transmit the escape
or control C characters, has
.BR 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'.
.PP
Other specific terminal problems may be corrected by adding more
capabilities of the form \fBx\fR\fIx\fR.
.PP
.SS Similar Terminals
.PP
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 \fBuse\fR can be given with
the name of the base terminal.
The capabilities given before
.B use
override those in the base type named by
.BR use .
If there are multiple \fBuse\fR capabilities, they are merged in reverse order.
That is, the rightmost \fBuse\fR reference is processed first, then the one to
its left, and so forth.
Capabilities given explicitly in the entry override
those brought in by \fBuse\fR references.
.PP
A capability can be canceled by placing \fBxx@\fR to the left of the
use reference that imports it, where \fIxx\fP is the capability.
For example, the entry
.PP
	2621-nl, smkx@, rmkx@, use=2621,
.PP
defines a 2621-nl that does not have the \fBsmkx\fR or \fBrmkx\fR 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.
.PP
.SS Pitfalls of Long Entries
.PP
Long terminfo entries are unlikely to be a problem; to date, no entry has even
approached terminfo's 4096-byte string-table maximum.
Unfortunately, the termcap
translations are much more strictly limited (to 1023 bytes), thus termcap translations
of long terminfo entries can cause problems.
.PP
The man pages for 4.3BSD and older versions of \fBtgetent()\fP instruct the user to
allocate a 1024-byte buffer for the termcap entry.
The entry gets null-terminated by
the termcap library, so that makes the maximum safe length for a termcap entry
1k-1 (1023) bytes.
Depending on what the application and the termcap library
being used does, and where in the termcap file the terminal type that \fBtgetent()\fP
is searching for is, several bad things can happen.
.PP
Some termcap libraries print a warning message or exit if they find an
entry that's longer than 1023 bytes; others do not; others truncate the
entries to 1023 bytes.
Some application programs allocate more than
the recommended 1K for the termcap entry; others do not.
.PP
Each termcap entry has two important sizes associated with it: before
"tc" expansion, and after "tc" expansion.
"tc" is the capability that
tacks on another termcap entry to the end of the current one, to add
on its capabilities.
If a termcap entry does not use the "tc"
capability, then of course the two lengths are the same.
.PP
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 \fBtgetent()\fP strips out while reading it.
Some termcap libraries strip off the final newline, too (GNU termcap does not).
Now suppose:
.TP 5
*
a termcap entry before expansion is more than 1023 bytes long,
.TP 5
*
and the application has only allocated a 1k buffer,
.TP 5
*
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,
.TP 5
*
and \fBtgetent()\fP is searching for a terminal type that either is the
long entry, appears in the termcap file after the long entry, or
does not appear in the file at all (so that \fBtgetent()\fP has to search
the whole termcap file).
.PP
Then \fBtgetent()\fP 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.
.PP
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 \fBtgetent()\fP only does "tc" expansion once it's found the
terminal type it was looking for, not while searching.
.PP
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.
.PP
When in -C (translate to termcap) mode, the \fBncurses\fR implementation of
\fBtic\fR(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.
.SS 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.
.SH EXTENSIONS
Some SVr4 \fBcurses\fR implementations, and all previous to SVr4, do not
interpret the %A and %O operators in parameter strings.
.PP
SVr4/XPG4 do not specify whether \fBmsgr\fR licenses movement while in
an alternate-character-set mode (such modes may, among other things, map
CR and NL to characters that do not trigger local motions).
The \fBncurses\fR implementation ignores \fBmsgr\fR in \fBALTCHARSET\fR
mode.
This raises the possibility that an XPG4
implementation making the opposite interpretation may need terminfo
entries made for \fBncurses\fR to have \fBmsgr\fR turned off.
.PP
The \fBncurses\fR library handles insert-character and insert-character modes
in a slightly non-standard way to get better update efficiency.
See
the \fBInsert/Delete Character\fR subsection above.
.PP
The parameter substitutions for \fBset_clock\fR and \fBdisplay_clock\fR are
not documented in SVr4 or the XSI Curses standard.
They are deduced from the
documentation for the AT&T 505 terminal.
.PP
Be careful assigning the \fBkmous\fR capability.
The \fBncurses\fR wants to
interpret it as \fBKEY_MOUSE\fR, for use by terminals and emulators like xterm
that can return mouse-tracking information in the keyboard-input stream.
.PP
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:
.PP
\fBSVR4, Solaris, ncurses\fR --
These support all SVr4 capabilities.
.PP
\fBSGI\fR --
Supports the SVr4 set, adds one undocumented extended string
capability (\fBset_pglen\fR).
.PP
\fBSVr1, Ultrix\fR --
These support a restricted subset of terminfo capabilities.
The booleans
end with \fBxon_xoff\fR; the numerics with \fBwidth_status_line\fR; and the
strings with \fBprtr_non\fR.
.PP
\fBHP/UX\fR --
Supports the SVr1 subset, plus the SVr[234] numerics \fBnum_labels\fR,
\fBlabel_height\fR, \fBlabel_width\fR, plus function keys 11 through 63, plus
\fBplab_norm\fR, \fBlabel_on\fR, and \fBlabel_off\fR, plus some incompatible
extensions in the string table.
.PP
\fBAIX\fR --
Supports the SVr1 subset, plus function keys 11 through 63, plus a number
of incompatible string table extensions.
.PP
\fBOSF\fR --
Supports both the SVr4 set and the AIX extensions.
.SH FILES
.TP 25
\*d/?/*
files containing terminal descriptions
.SH SEE ALSO
\fBtic\fR(1M),
\fBinfocmp\fR(1M),
\fBcurses\fR(3X),
\fBprintf\fR(3S),
\fBterm\fR(\*n).
.SH AUTHORS
Zeyd M. Ben-Halim, Eric S. Raymond, Thomas E. Dickey.
Based on pcurses by Pavel Curtis.
.\"#
.\"# The following sets edit modes for GNU EMACS
.\"# Local Variables:
.\"# mode:nroff
.\"# fill-column:79
.\"# End: