termcap.texi

linux下bash的源码

the terminal's margin-wrap switch is on; it contains the @samp{am}
flag.  The implication is that normally the switch is off and the
usual description for the terminal says that the switch is off.

@item -nam
``No automatic margins''.  The opposite of @samp{-am}, this names an
alternative description which lacks the @samp{am} flag.  This implies
that the terminal is normally operated with the margin-wrap switch
turned on, and the normal description of the terminal says so.

@item -na
``No arrows''.  This terminal description initializes the terminal to
keep its arrow keys in local mode.  This is a user option.

@item -rv
``Reverse video''.  This terminal description causes text output for
normal video to appear as reverse, and text output for reverse video
to come out as normal.  Often this description differs from the usual
one by interchanging the two strings which turn reverse video on and
off.@refill

This is a user option; you can choose either the ``reverse video''
variant terminal type or the normal terminal type, and termcap will
obey.

@item -s
``Status''.  Says to enable use of a status line which ordinary output
does not touch (@pxref{Status Line}).

Some terminals have a special line that is used only as a status line.
For these terminals, there is no need for an @samp{-s} variant; the
status line commands should be defined by default.  On other
terminals, enabling a status line means removing one screen line from
ordinary use and reducing the effective screen height.  For these
terminals, the user can choose the @samp{-s} variant type to request
use of a status line.

@item -@var{nlines}
Says to operate with @var{nlines} lines on the screen, for terminals
such as the Ambassador which provide this as an option.  Normally this
is a user option; by choosing the terminal type, you control how many
lines termcap will use.

@item -@var{npages}p
Says that the terminal has @var{npages} pages worth of screen memory,
for terminals where this is a hardware option.

@item -unk
Says that description is not for direct use, but only for reference in
@samp{tc} capabilities.  Such a description is a kind of subroutine,
because it describes the common characteristics of several variant
descriptions that would use other suffixes in place of @samp{-unk}.
@end table

@node Inheriting, Changing, Naming, Data Base
@section Inheriting from Related Descriptions

@cindex inheritance
When two terminal descriptions are similar, their identical parts do not
need to be given twice.  Instead, one of the two can be defined in terms of
the other, using the @samp{tc} capability.  We say that one description
@dfn{refers to} the other, or @dfn{inherits from} the other.

The @samp{tc} capability must be the last one in the terminal description,
and its value is a string which is the name of another terminal type which
is referred to.  For example,

@example
N9|aaa|ambassador|aaa-30|ann arbor ambassador/30 lines:\
        :ti=\E[2J\E[30;0;0;30p:\
        :te=\E[60;0;0;30p\E[30;1H\E[J:\
        :li#30:tc=aaa-unk:
@end example

@noindent
defines the terminal type @samp{aaa-30} (also known as plain @samp{aaa}) in
terms of @samp{aaa-unk}, which defines everything about the Ambassador that
is independent of screen height.  The types @samp{aaa-36}, @samp{aaa-48}
and so on for other screen heights are likewise defined to inherit from
@samp{aaa-unk}.

The capabilities overridden by @samp{aaa-30} include @samp{li}, which says
how many lines there are, and @samp{ti} and @samp{te}, which configure the
terminal to use that many lines.

The effective terminal description for type @samp{aaa} consists of the text
shown above followed by the text of the description of @samp{aaa-unk}.  The
@samp{tc} capability is handled automatically by @code{tgetent}, which
finds the description thus referenced and combines the two descriptions
(@pxref{Find}).  Therefore, only the implementor of the terminal
descriptions needs to think about using @samp{tc}.  Users and application
programmers do not need to be concerned with it.

Since the reference terminal description is used last, capabilities
specified in the referring description override any specifications of the
same capabilities in the reference description.

The referring description can cancel out a capability without specifying
any new value for it by means of a special trick.  Write the capability in
the referring description, with the character @samp{@@} after the capability
name, as follows:

@smallexample
NZ|aaa-30-nam|ann arbor ambassador/30 lines/no automatic-margins:\
        :am@@:tc=aaa-30:
@end smallexample

@node Changing,  , Inheriting, Data Base
@section When Changes in the Data Base Take Effect

Each application program must read the terminal description from the
data base, so a change in the data base is effective for all jobs started
after the change is made.

The change will usually have no effect on a job that have been in existence
since before the change. The program probably read the terminal description
once, when it was started, and is continuing to use what it read then.
If the program does not have a feature for reexamining the data base, then
you will need to run it again (probably killing the old job).

If the description in use is coming from the @code{TERMCAP} environment
variable, then the data base file is effectively overridden, and changes in
it will have no effect until you change the @code{TERMCAP} variable as
well.  For example, some users' @file{.login} files automatically copy the
terminal description into @code{TERMCAP} to speed startup of applications.
If you have done this, you will need to change the @code{TERMCAP} variable
to make the changed data base take effect.

@node Capabilities, Summary, Data Base, Top
@chapter Definitions of the Terminal Capabilities

This section is divided into many subsections, each for one aspect of
use of display terminals.  For writing a display program, you usually need
only check the subsections for the operations you want to use.  For writing
a terminal description, you must read each subsection and fill in the
capabilities described there.

String capabilities that are display commands may require numeric
parameters (@pxref{Parameters}).  Most such capabilities do not use
parameters.  When a capability requires parameters, this is explicitly
stated at the beginning of its definition.  In simple cases, the first or
second sentence of the definition mentions all the parameters, in the order
they should be given, using a name
@iftex
in italics
@end iftex
@ifinfo
in upper case
@end ifinfo
for each one.  For example, the @samp{rp} capability is a command that
requires two parameters; its definition begins as follows:

@quotation
String of commands to output a graphic character @var{c}, repeated @var{n}
times.
@end quotation

In complex cases or when there are many parameters, they are described
explicitly.

When a capability is described as obsolete, this means that programs should
not be written to look for it, but terminal descriptions should still be
written to provide it.

When a capability is described as very obsolete, this means that it should
be omitted from terminal descriptions as well.

@menu
* Basic::       Basic characteristics.
* Screen Size::  Screen size, and what happens when it changes.
* Cursor Motion::  Various ways to move the cursor.
* Wrapping::    What happens if you write a character in the last column.
* Scrolling::   Pushing text up and down on the screen.
* Windows::     Limiting the part of the window that output affects.
* Clearing::    Erasing one or many lines.
* Insdel Line::  Making new blank lines in mid-screen; deleting lines.
* Insdel Char::  Inserting and deleting characters within a line.
* Standout::    Highlighting some of the text.
* Underlining::  Underlining some of the text.
* Cursor Visibility::  Making the cursor more or less easy to spot.
* Bell::        Attracts user's attention; not localized on the screen.
* Keypad::      Recognizing when function keys or arrows are typed.
* Meta Key::    @key{META} acts like an extra shift key.
* Initialization::  Commands used to initialize or reset the terminal.
* Pad Specs::   Info for the kernel on how much padding is needed.
* Status Line::  A status line displays ``background'' information.
* Half-Line::   Moving by half-lines, for superscripts and subscripts.
* Printer::     Controlling auxiliary printers of display terminals.
@end menu

@node Basic, Screen Size,  , Capabilities
@section Basic Characteristics

This section documents the capabilities that describe the basic and
nature of the terminal, and also those that are relevant to the output
of graphic characters.

@table @samp
@item os
@kindex os
@cindex overstrike
Flag whose presence means that the terminal can overstrike.  This
means that outputting a graphic character does not erase whatever was
present in the same character position before.  The terminals that can
overstrike include printing terminals, storage tubes (all obsolete
nowadays), and many bit-map displays.

@item eo
@kindex eo
Flag whose presence means that outputting a space erases a character
position even if the terminal supports overstriking.  If this flag is
not present and overstriking is supported, output of a space has no
effect except to move the cursor.

(On terminals that do not support overstriking, you can always assume
that outputting a space at a position erases whatever character was
previously displayed there.)

@item gn
@kindex gn
@cindex generic terminal type
Flag whose presence means that this terminal type is a generic type
which does not really describe any particular terminal.  Generic types
are intended for use as the default type assigned when the user
connects to the system, with the intention that the user should
specify what type he really has.  One example of a generic type
is the type @samp{network}.

Since the generic type cannot say how to do anything interesting with
the terminal, termcap-using programs will always find that the
terminal is too weak to be supported if the user has failed to specify
a real terminal type in place of the generic one.  The @samp{gn} flag
directs these programs to use a different error message: ``You have
not specified your real terminal type'', rather than ``Your terminal
is not powerful enough to be used''.

@item hc
@kindex hc
Flag whose presence means this is a hardcopy terminal.

@item rp
@kindex rp
@cindex repeat output
String of commands to output a graphic character @var{c}, repeated @var{n}
times.  The first parameter value is the ASCII code for the desired
character, and the second parameter is the number of times to repeat the
character.  Often this command requires padding proportional to the 
number of times the character is repeated.  This effect can be had by
using parameter arithmetic with @samp{%}-sequences to compute the
amount of padding, then generating the result as a number at the front
of the string so that @code{tputs} will treat it as padding.

@item hz
@kindex hz
Flag whose presence means that the ASCII character @samp{~} cannot be
output on this terminal because it is used for display commands.

Programs handle this flag by checking all text to be output and
replacing each @samp{~} with some other character(s).  If this is not
done, the screen will be thoroughly garbled.

The old Hazeltine terminals that required such treatment are probably
very rare today, so you might as well not bother to support this flag.

@item CC
@kindex CC
@cindex command character
String whose presence means the terminal has a settable command
character.  The value of the string is the default command character
(which is usually @key{ESC}).

All the strings of commands in the terminal description should be
written to use the default command character.  If you are writing an
application program that changes the command character, use the
@samp{CC} capability to figure out how to translate all the display
commands to work with the new command character.

Most programs have no reason to look at the @samp{CC} capability.

@item xb
@kindex xb
@cindex Superbee
Flag whose presence identifies Superbee terminals which are unable to
transmit the characters @key{ESC} and @kbd{Control-C}.  Programs which
support this flag are supposed to check the input for the code sequences
sent by the @key{F1} and @key{F2} keys, and pretend that @key{ESC}
or @kbd{Control-C} (respectively) had been read.  But this flag is
obsolete, and not worth supporting.
@end table

@node Screen Size, Cursor Motion, Basic, Capabilities
@section Screen Size
@cindex screen size

A terminal description has two capabilities, @samp{co} and @samp{li},
that describe the screen size in columns and lines.  But there is more
to the question of screen size than this.

On some operating systems the ``screen'' is really a window and the
effective width can vary.  On some of these systems, @code{tgetnum}
uses the actual width of the window to decide what value to return for
the @samp{co} capability, overriding what is actually written in the
terminal description.  On other systems, it is up to the application
program to check the actual window width using a system call.  For
example, on BSD 4.3 systems, the system call @code{ioctl} with code
@code{TIOCGWINSZ} will tell you the current screen size.

On all window systems, termcap is powerless to advise the application
program if the user resizes the window.  Application programs must
deal with this possibility in a system-dependent fashion.  On some
systems the C shell handles part of the problem by detecting changes
in window size and setting the @code{TERMCAP} environment variable
appropriately.  This takes care of applicati