man/terminfo.head

   1 .\"***************************************************************************
   2 .\" Copyright (c) 1998-2018,2019 Free Software Foundation, Inc.              *
   3 .\"                                                                          *
   4 .\" Permission is hereby granted, free of charge, to any person obtaining a  *
   5 .\" copy of this software and associated documentation files (the            *
   6 .\" "Software"), to deal in the Software without restriction, including      *
   7 .\" without limitation the rights to use, copy, modify, merge, publish,      *
   8 .\" distribute, distribute with modifications, sublicense, and/or sell       *
   9 .\" copies of the Software, and to permit persons to whom the Software is    *
  10 .\" furnished to do so, subject to the following conditions:                 *
  11 .\"                                                                          *
  12 .\" The above copyright notice and this permission notice shall be included  *
  13 .\" in all copies or substantial portions of the Software.                   *
  14 .\"                                                                          *
  15 .\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS  *
  16 .\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF               *
  17 .\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.   *
  18 .\" IN NO EVENT SHALL THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,   *
  19 .\" DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR    *
  20 .\" OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR    *
  21 .\" THE USE OR OTHER DEALINGS IN THE SOFTWARE.                               *
  22 .\"                                                                          *
  23 .\" Except as contained in this notice, the name(s) of the above copyright   *
  24 .\" holders shall not be used in advertising or otherwise to promote the     *
  25 .\" sale, use or other dealings in this Software without prior written       *
  26 .\" authorization.                                                           *
  27 .\"***************************************************************************
  28 .\"
  29 .\" $Id: terminfo.head,v 1.38 2019/07/27 11:51:04 tom Exp $
  30 .TH terminfo 5 "" "" "File Formats"
  31 .ds n 5
  32 .ds d @TERMINFO@
  33 .ie \n(.g .ds `` \(lq
  34 .el       .ds `` ``
  35 .ie \n(.g .ds '' \(rq
  36 .el       .ds '' ''
  37 .de bP
  38 .ie n  .IP \(bu 4
  39 .el    .IP \(bu 2
  40 ..
  41 .de NS
  42 .ie n  .sp
  43 .el    .sp .5
  44 .ie n  .in +4
  45 .el    .in +2
  46 .nf
  47 .ft C                   \" Courier
  48 ..
  49 .de NE
  50 .fi
  51 .ft R
  52 .ie n  .in -4
  53 .el    .in -2
  54 ..
  55 .SH NAME
  56 terminfo \- terminal capability data base
  57 .SH SYNOPSIS
  58 \*d/*/*
  59 .SH DESCRIPTION
  60 .I Terminfo
  61 is a data base describing terminals,
  62 used by screen-oriented programs such as
  63 \fBnvi\fR(1),
  64 \fBlynx\fR(1),
  65 \fBmutt\fR(1),
  66 and other curses applications,
  67 using high-level calls to libraries such as \fBcurses\fR(3X).
  68 It is also used via low-level calls by non-curses applications
  69 which may be screen-oriented (such as \fB@CLEAR@\fP(1))
  70 or non-screen (such as \fB@TABS@\fP(1)).
  71 .PP
  72 .I Terminfo
  73 describes terminals by giving a set of capabilities which they
  74 have, by specifying how to perform screen operations, and by
  75 specifying padding requirements and initialization sequences.
  76 .PP
  77 This manual describes \fBncurses\fR
  78 version @NCURSES_MAJOR@.@NCURSES_MINOR@ (patch @NCURSES_PATCH@).
  79 .SS Terminfo Entry Syntax
  80 .PP
  81 Entries in
  82 .I terminfo
  83 consist of a sequence of fields:
  84 .bP
  85 Each field ends with a comma \*(``,\*(''
  86 (embedded commas may be
  87 escaped with a backslash or written as \*(``\\054\*('').
  88 .bP
  89 White space between fields is ignored.
  90 .bP
  91 The first field in a \fIterminfo\fP entry begins in the first column.
  92 .bP
  93 Newlines and leading whitespace (spaces or tabs)
  94 may be used for formatting entries for readability.
  95 These are removed from parsed entries.
  96 .IP
  97 The \fB@INFOCMP@\fP \fB\-f\fP and \fB\-W\fP options rely on this to
  98 format if-then-else expressions,
  99 or to enforce maximum line-width.
 100 The resulting formatted terminal description can be read by \fB@TIC@\fP.
 101 .bP
 102 The first field for each terminal gives the names which are known for the
 103 terminal, separated by \*(``|\*('' characters.
 104 .IP
 105 The first name given is the most common abbreviation for the terminal
 106 (its primary name),
 107 the last name given should be a long name fully identifying the terminal
 108 (see \fBlongname\fP(3X)),
 109 and all others are treated as synonyms (aliases) for the primary terminal name.
 110 .IP
 111 X/Open Curses advises that all names but the last should be in lower case
 112 and contain no blanks;
 113 the last name may well contain upper case and blanks for readability.
 114 .IP
 115 This implementation is not so strict;
 116 it allows mixed case in the primary name and aliases.
 117 If the last name has no embedded blanks,
 118 it allows that to be both an alias and a verbose name
 119 (but will warn about this ambiguity).
 120 .bP
 121 Lines beginning with a \*(``#\*('' in the first column are treated as comments.
 122 .IP
 123 While comment lines are legal at any point, the output of \fB@CAPTOINFO@\fP
 124 and \fB@INFOTOCAP@\fP (aliases for \fB@TIC@\fP)
 125 will move comments so they occur only between entries.
 126 .PP
 127 Terminal names (except for the last, verbose entry) should
 128 be chosen using the following conventions.
 129 The particular piece of hardware making up the terminal should
 130 have a root name, thus \*(``hp2621\*(''.
 131 This name should not contain hyphens.
 132 Modes that the hardware can be in, or user preferences, should
 133 be indicated by appending a hyphen and a mode suffix.
 134 Thus, a vt100 in 132-column mode would be vt100\-w.
 135 The following suffixes should be used where possible:
 136 .PP
 137 .TS
 138 center ;
 139 l c l
 140 l l l.
 141 \fBSuffix       Meaning Example\fP
 142 \-\fInn\fP      Number of lines on the screen   aaa\-60
 143 \-\fIn\fPp      Number of pages of memory       c100\-4p
 144 \-am    With automargins (usually the default)  vt100\-am
 145 \-m     Mono mode; suppress color               ansi\-m
 146 \-mc    Magic cookie; spaces when highlighting  wy30\-mc
 147 \-na    No arrow keys (leave them in local)     c100\-na
 148 \-nam   Without automatic margins               vt100\-nam
 149 \-nl    No status line                          att4415\-nl
 150 \-ns    No status line                          hp2626\-ns
 151 \-rv    Reverse video                           c100\-rv
 152 \-s     Enable status line                      vt100\-s
 153 \-vb    Use visible bell instead of beep        wy370\-vb
 154 \-w     Wide mode (> 80 columns, usually 132)   vt100\-w
 155 .TE
 156 .PP
 157 For more on terminal naming conventions, see the \fBterm\fP(7) manual page.
 158 .SS Terminfo Capabilities Syntax
 159 .PP
 160 The terminfo entry consists of several \fIcapabilities\fP,
 161 i.e., features that the terminal has,
 162 or methods for exercising the terminal's features.
 163 .PP
 164 After the first field (giving the name(s) of the terminal entry),
 165 there should be one or more \fIcapability\fP fields.
 166 These are boolean, numeric or string names with corresponding values:
 167 .bP
 168 Boolean capabilities are true when present, false when absent.
 169 There is no explicit value for boolean capabilities.
 170 .bP
 171 Numeric capabilities have a \*(``#\*('' following the name,
 172 then an unsigned decimal integer value.
 173 .bP
 174 String capabilities have a \*(``=\*('' following the name,
 175 then an string of characters making up the capability value.
 176 .IP
 177 String capabilities can be split into multiple lines,
 178 just as the fields comprising a terminal entry can be
 179 split into multiple lines.
 180 While blanks between fields are ignored,
 181 blanks embedded within a string value are retained,
 182 except for leading blanks on a line.
 183 .PP
 184 Any capability can be \fIcanceled\fP,
 185 i.e., suppressed from the terminal entry,
 186 by following its name with \*(``@\*(''
 187 rather than a capability value.
 188 .SS Similar Terminals
 189 .PP
 190 If there are two very similar terminals, one (the variant) can be defined as
 191 being just like the other (the base) with certain exceptions.
 192 In the
 193 definition of the variant, the string capability \fBuse\fR can be given with
 194 the name of the base terminal:
 195 .bP
 196 The capabilities given before
 197 .B use
 198 override those in the base type named by
 199 .BR use .
 200 .bP
 201 If there are multiple \fBuse\fR capabilities, they are merged in reverse order.
 202 That is, the rightmost \fBuse\fR reference is processed first, then the one to
 203 its left, and so forth.
 204 .bP
 205 Capabilities given explicitly in the entry override
 206 those brought in by \fBuse\fR references.
 207 .PP
 208 A capability can be canceled by placing \fBxx@\fR to the left of the
 209 use reference that imports it, where \fIxx\fP is the capability.
 210 For example, the entry
 211 .RS
 212 .PP
 213 2621\-nl, smkx@, rmkx@, use=2621,
 214 .RE
 215 .PP
 216 defines a 2621\-nl that does not have the \fBsmkx\fR or \fBrmkx\fR capabilities,
 217 and hence does not turn on the function key labels when in visual mode.
 218 This is useful for different modes for a terminal, or for different
 219 user preferences.
 220 .PP
 221 An entry included via \fBuse\fP can contain canceled capabilities,
 222 which have the same effect as if those cancels were inline in the
 223 using terminal entry.
 224 .SS Predefined Capabilities
 225 .\" Head of terminfo man page ends here
 226 .ps -1