<!--
* t
****************************************************************************
- * Copyright 2018-2021,2023 Thomas E. Dickey *
+ * Copyright 2018-2023,2024 Thomas E. Dickey *
* Copyright 1998-2016,2017 Free Software Foundation, Inc. *
* *
* Permission is hereby granted, free of charge, to any person obtaining a *
* sale, use or other dealings in this Software without prior written *
* authorization. *
****************************************************************************
- * @Id: term.5,v 1.70 2023/12/30 21:36:32 tom Exp @
+ * @Id: term.5,v 1.80 2024/06/15 20:23:33 tom Exp @
-->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="generator" content="Manpage converted by man2html - see https://invisible-island.net/scripts/readme.html#others_scripts">
-<TITLE>term 5 2023-12-30 ncurses 6.4 File formats</TITLE>
+<TITLE>term 5 2024-06-15 ncurses 6.5 File formats</TITLE>
<link rel="author" href="mailto:bug-ncurses@gnu.org">
</HEAD>
<BODY>
-<H1 class="no-header">term 5 2023-12-30 ncurses 6.4 File formats</H1>
+<H1 class="no-header">term 5 2024-06-15 ncurses 6.5 File formats</H1>
<PRE>
<STRONG><A HREF="term.5.html">term(5)</A></STRONG> File formats <STRONG><A HREF="term.5.html">term(5)</A></STRONG>
term - compiled <EM>terminfo</EM> terminal description
-</PRE><H2><a name="h2-SYNOPSIS">SYNOPSIS</a></H2><PRE>
- <STRONG>term</STRONG>
-
-
</PRE><H2><a name="h2-DESCRIPTION">DESCRIPTION</a></H2><PRE>
+ <STRONG><A HREF="tic.1m.html">tic(1)</A></STRONG> compiles a <EM>terminfo</EM> terminal type description, and <STRONG><A HREF="curs_terminfo.3x.html">setupterm(3x)</A></STRONG>
+ reads it. A compiled description may be stored in a file or in a
+ database of, potentially, many such descriptions. Further, a compiled
+ description may be in one of two formats: one similar to that used by
+ System V, and a newer, extensible format employed exclusively by
+ <EM>ncurses</EM>.
+
</PRE><H3><a name="h3-Storage-Location">Storage Location</a></H3><PRE>
- Compiled terminfo descriptions are placed under the directory
- <STRONG>/usr/share/terminfo</STRONG>. Two configurations are supported (when building
- the <EM>ncurses</EM> libraries):
+ Compiled <EM>terminfo</EM> <EM>descriptions</EM> <EM>are</EM> <EM>placed</EM> under the directory
+ <EM>/usr/share/terminfo</EM>. One of two configurations is selected when
+ building the <EM>ncurses</EM> libraries.
<STRONG>directory</STRONG> <STRONG>tree</STRONG>
A two-level scheme is used to avoid a linear search of a huge Unix
- system directory: <STRONG>/usr/share/terminfo/c/name</STRONG> where <EM>name</EM> is the
+ system directory: <EM>/usr/share/terminfo/</EM>c<EM>/</EM>name where <EM>name</EM> is the
name of the terminal, and <EM>c</EM> is the first character of <EM>name</EM>. Thus,
- <EM>act4</EM> can be found in the file <STRONG>/usr/share/terminfo/a/act4</STRONG>.
- Synonyms for the same terminal are implemented by multiple links
- to the same compiled file.
+ the compiled description of terminal type "act4" is found in the
+ file <EM>/usr/share/terminfo/a/act4</EM>. Synonyms for the same terminal
+ are implemented by multiple links to the same compiled file.
<STRONG>hashed</STRONG> <STRONG>database</STRONG>
- Using Berkeley database, two types of records are stored: the
- terminfo data in the same format as stored in a directory tree
- with the terminfo's primary name as a key, and records containing
- only aliases pointing to the primary name.
-
- If built to write hashed databases, <EM>ncurses</EM> can still read
- terminfo databases organized as a directory tree, but cannot write
- entries into the directory tree. It can write (or rewrite)
+ Using the Berkeley database API, two types of records are stored:
+ the <EM>terminfo</EM> data in the same format as that stored in a directory
+ tree with the terminal's primary type name as a key, and records
+ containing only aliases pointing to the primary name.
+
+ If built to write hashed databases, <EM>ncurses</EM> can still read <EM>term-</EM>
+ <EM>info</EM> databases organized as a directory tree, but cannot write
+ entries into the directory tree. It can write (or rewrite)
entries in the hashed database.
- <EM>ncurses</EM> distinguishes the two cases in the <EM>TERMINFO</EM> and
- <EM>TERMINFO</EM><STRONG>_</STRONG><EM>DIRS</EM> environment variable by assuming a directory tree
- for entries that correspond to an existing directory, and hashed
+ <EM>ncurses</EM> distinguishes the two cases in the <EM>TERMINFO</EM> and
+ <EM>TERMINFO</EM><STRONG>_</STRONG><EM>DIRS</EM> environment variable by assuming a directory tree
+ for entries that correspond to an existing directory, and a hashed
database otherwise.
</PRE><H3><a name="h3-Legacy-Storage-Format">Legacy Storage Format</a></H3><PRE>
The format has been chosen so that it will be the same on all hardware.
- An 8 or more bit byte is assumed, but no assumptions about byte
- ordering or sign extension are made.
+ A byte of at least eight bits' width is assumed, but no assumptions
+ about bit ordering or sign extension are made.
- The compiled file is created with the <STRONG>tic</STRONG> program, and read by the
- routine <STRONG><A HREF="curs_terminfo.3x.html">setupterm(3x)</A></STRONG>. The file is divided into six parts:
+ The file is divided into six parts:
- a) <EM>header</EM>,
+ (a) <EM>header</EM>,
- b) <EM>terminal</EM> <EM>names</EM>,
+ (b) <EM>terminal</EM> <EM>names</EM>,
- c) <EM>Boolean</EM> <EM>flags</EM>,
+ (c) <EM>Boolean</EM> <EM>flags</EM>,
- d) <EM>numbers</EM>,
+ (d) <EM>numbers</EM>,
- e) <EM>strings</EM>, and
+ (e) <EM>strings</EM>, and
- f) <EM>string</EM> <EM>table</EM>.
+ (f) a <EM>string</EM> <EM>table</EM>.
The <EM>header</EM> section begins the file. This section contains six short
integers in the format described below. These integers are
- (1) the <EM>magic</EM> <EM>number</EM> (octal 0432);
+ (1) the <EM>magic</EM> <EM>number</EM>
+ (octal 0432);
- (2) the size, in bytes, of the <EM>terminal</EM> <EM>names</EM> section;
+ (2) the size,
+ in bytes, of the <EM>terminal</EM> <EM>names</EM> section;
(3) the number of bytes in the <EM>Boolean</EM> <EM>flags</EM> section;
(4) the number of short integers in the <EM>numbers</EM> section;
- (5) the number of offsets (short integers) in the <EM>strings</EM> section;
+ (5) the number of offsets
+ (short integers) in the <EM>strings</EM> section;
- (6) the size, in bytes, of the <EM>string</EM> <EM>table</EM>.
+ (6) the size,
+ in bytes, of the <EM>string</EM> <EM>table</EM>.
The capabilities in the <EM>Boolean</EM> <EM>flags</EM>, <EM>numbers</EM>, and <EM>strings</EM> sections
- are in the same order as the file <term.h>.
+ are in the same order as in the header file <EM>term.h</EM>.
- Short integers are signed, in the range -32768 to 32767. They are
- stored as two 8-bit bytes. The first byte contains the least
- significant 8 bits of the value, and the second byte contains the most
- significant 8 bits. (Thus, the value represented is 256*second+first.)
- This format corresponds to the hardware of the VAX and PDP-11 (that is,
- little-endian machines). Machines where this does not correspond to
- the hardware must read the integers as two bytes and compute the
- little-endian value.
+ Short integers are signed, in the range -32768 to 32767, and stored in
+ little-endian format.
Numbers in a terminal description, whether they are entries in the
<EM>numbers</EM> or <EM>strings</EM> table, are positive integers. Boolean flags are
treated as positive one-byte integers. In each case, those positive
- integers represent a terminal capability. The terminal compiler tic
+ integers represent a terminal capability. The terminal compiler <EM>tic</EM>
uses negative integers to handle the cases where a capability is not
available:
- <STRONG>o</STRONG> If a capability is absent from this terminal, tic stores a -1 in
+ <STRONG>o</STRONG> If a capability is absent from this terminal, <EM>tic</EM> stores a -1 in
the corresponding table.
The integer value -1 is represented by two bytes 0377, 0377.
Absent Boolean values are represented by the byte 0 (false).
- <STRONG>o</STRONG> If a capability has been canceled from this terminal, tic stores a
+ <STRONG>o</STRONG> If a capability has been canceled from this terminal, <EM>tic</EM> stores a
-2 in the corresponding table.
The integer value -2 is represented by two bytes 0377, 0376.
<STRONG>o</STRONG> Other negative values are illegal.
The <EM>terminal</EM> <EM>names</EM> section comes after the <EM>header</EM>. It contains the
- first line of the terminfo description, listing the various names for
+ first line of the <EM>terminfo</EM> description, listing the various names for
the terminal, separated by the "|" character. The <EM>terminal</EM> <EM>names</EM>
section is terminated with an ASCII NUL character.
string capabilities referenced in the <EM>strings</EM> section. Each string is
null-terminated. Special characters in ^X or \c notation are stored in
their interpreted form, not the printing representation. Padding
- information $<nn> and parameter information %x are stored intact in
+ information <STRONG>$<</STRONG><EM>nn</EM><STRONG>></STRONG> and parameter information <STRONG>%x</STRONG> are stored intact in
uninterpreted form.
</PRE><H3><a name="h3-Extended-Storage-Format">Extended Storage Format</a></H3><PRE>
- The previous section describes the conventional terminfo binary format.
+ The previous section describes the conventional <EM>terminfo</EM> binary format.
With some minor variations of the offsets (see PORTABILITY), the same
binary format is used in all modern Unix systems. Each system uses a
predefined set of Boolean, number or string capabilities.
- The <EM>ncurses</EM> libraries and applications support extended terminfo binary
- format, allowing users to define capabilities which are loaded at
+ The <EM>ncurses</EM> libraries and applications support extended <EM>terminfo</EM> binary
+ format, allowing users to define capabilities that are loaded at
runtime. This extension is made possible by using the fact that the
- other implementations stop reading the terminfo data when they have
- reached the end of the size given in the header. <EM>ncurses</EM> checks the
- size, and if it exceeds that due to the predefined data, continues to
- parse according to its own scheme.
+ other implementations stop reading the <EM>terminfo</EM> data when they reach
+ the end of the size given in the header. <EM>ncurses</EM> checks the size, and
+ if it exceeds that due to the predefined data, continues to parse
+ according to its own scheme.
First, it reads the extended header (5 short integers):
The extended string table contains values for string capabilities.
After the end of these values, it contains the names for each of the
- extended capabilities in order, e.g., Booleans, then numbers and
- finally strings.
+ extended capabilities in order: Boolean, numeric, and string.
- By storing terminal descriptions in this way, <EM>ncurses</EM> is able to
+ By storing terminal descriptions in this way, <EM>ncurses</EM> is able to
provide a database useful with legacy applications, as well as
- providing data for applications which need more than the predefined
- capabilities. See <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG> for an overview of the way <EM>ncurses</EM> uses
- this extended information.
+ providing data for applications that require more information about a
+ terminal type than was anticipated by X/Open Curses. See <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG>
+ for an overview of the way <EM>ncurses</EM> uses this extended information.
- Applications which manipulate terminal data can use the definitions
- described in <STRONG><A HREF="term_variables.3x.html">term_variables(3x)</A></STRONG> which associate the long capability
- names with members of a <STRONG>TERMTYPE</STRONG> structure.
+ Applications that manipulate terminal data can use the definitions
+ described in <STRONG><A HREF="term_variables.3x.html">term_variables(3x)</A></STRONG> associating the long capability names
+ with members of a <EM>TERMTYPE</EM> structure.
</PRE><H3><a name="h3-Extended-Number-Format">Extended Number Format</a></H3><PRE>
- On occasion, 16-bit signed integers are not large enough. With <EM>ncurses</EM>
- 6.1, a new format was introduced by making a few changes to the legacy
- format:
+ On occasion, 16-bit signed integers are not large enough. <EM>ncurses</EM> 6.1
+ introduced a new format by making a few changes to the legacy format:
<STRONG>o</STRONG> a different magic number (octal 01036)
to signed 32-bit integers.
To maintain compatibility, the library presents the same data
- structures to direct users of the <STRONG>TERMTYPE</STRONG> structure as in previous
+ structures to direct users of the <EM>TERMTYPE</EM> structure as in previous
formats. However, that cannot provide callers with the extended
numbers. The library uses a similar but hidden data structure
- <STRONG>TERMTYPE2</STRONG> to provide data for the terminfo functions.
+ <EM>TERMTYPE2</EM> to provide data for the <EM>terminfo</EM> functions.
</PRE><H2><a name="h2-FILES">FILES</a></H2><PRE>
</PRE><H3><a name="h3-Binary-Format">Binary Format</a></H3><PRE>
- X/Open Curses does not specify a format for the terminfo database.
- System V curses used a directory-tree of binary files, one per terminal
+ X/Open Curses does not specify a format for the <EM>terminfo</EM> database.
+ System V <EM>curses</EM> used a directory-tree of binary files, one per terminal
description.
- Despite the consistent use of little-endian for numbers and the
- otherwise self-describing format, it is not wise to count on
- portability of binary terminfo entries between commercial Unix
- versions. The problem is that there are at least three versions of
- terminfo (under HP-UX, AIX, and OSF/1) 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. See <STRONG><A HREF="terminfo.5.html">terminfo(5)</A></STRONG> for detailed discussion of terminfo
- source compatibility issues.
-
- This implementation is by default compatible with the binary terminfo
- format used by Solaris curses, except in a few less-used details where
+ Despite the consistent use of little-endian numbers and the otherwise
+ self-describing format, it is not wise to count on portability of
+ binary <EM>terminfo</EM> entries between commercial Unix versions. The problem
+ is that there are at least three versions of <EM>terminfo</EM> (under HP-UX,
+ AIX, and OSF/1) each of which diverged from System V <EM>terminfo</EM> after
+ SVr1, and added extension capabilities to the string table that (in the
+ binary format) collide with System V and X/Open Curses extensions. See
+ <STRONG><A HREF="terminfo.5.html">terminfo(5)</A></STRONG> for detailed discussion of <EM>terminfo</EM> source compatibility
+ issues.
+
+ This implementation is by default compatible with the binary <EM>terminfo</EM>
+ format used by Solaris <EM>curses</EM>, except in a few less-used details where
it was found that the latter did not match X/Open Curses. The format
used by the other Unix versions can be matched by building <EM>ncurses</EM> with
different configuration options.
</PRE><H3><a name="h3-Magic-Codes">Magic Codes</a></H3><PRE>
- The magic number in a binary terminfo file is the first 16-bits (two
+ The magic number in a binary <EM>terminfo</EM> file is the first 16 bits (two
bytes). Besides making it more reliable for the library to check that
- a file is terminfo, utilities such as <STRONG>file(1)</STRONG> also use that to tell
+ a file is <EM>terminfo</EM>, utilities such as <STRONG>file(1)</STRONG> also use that to tell
what the file-format is. System V defined more than one magic number,
with 0433, 0435 as screen-dumps (see <STRONG><A HREF="scr_dump.5.html">scr_dump(5)</A></STRONG>). This implementation
uses 01036 as a continuation of that sequence, but with a different
high-order byte to avoid confusion.
<STRONG>The</STRONG> <EM>TERMTYPE</EM> <STRONG>Structure</STRONG>
- Direct access to the <STRONG>TERMTYPE</STRONG> structure is provided for legacy
- applications. Portable applications should use the <STRONG>tigetflag</STRONG> and
- related functions described in <STRONG><A HREF="curs_terminfo.3x.html">curs_terminfo(3x)</A></STRONG> for reading terminal
- capabilities.
+ Direct access to the <EM>TERMTYPE</EM> structure is provided for legacy
+ applications. Portable applications should use <STRONG><A HREF="curs_terminfo.3x.html">tigetflag(3x)</A></STRONG> and
+ related functions to read terminal capabilities.
</PRE><H3><a name="h3-Mixed-case-Terminal-Names">Mixed-case Terminal Names</a></H3><PRE>
- A small number of terminal descriptions use uppercase characters in
- their names. If the underlying filesystem ignores the difference
- between uppercase and lowercase, <EM>ncurses</EM> represents the "first
- character" of the terminal name used as the intermediate level of a
+ A small number of terminal descriptions use uppercase characters in
+ their names. If the underlying file system ignores the difference
+ between uppercase and lowercase, <EM>ncurses</EM> represents the "first
+ character" of the terminal name used as the intermediate level of a
directory tree in (two-character) hexadecimal form.
</PRE><H3><a name="h3-Limits">Limits</a></H3><PRE>
<EM>ncurses</EM> stores compiled terminal descriptions in three related formats,
- described in the sections
+ described in the subsections
- <STRONG>o</STRONG> <STRONG>LEGACY</STRONG> <STRONG>STORAGE</STRONG> <STRONG>FORMAT</STRONG>, and
+ <STRONG>o</STRONG> <STRONG>Legacy</STRONG> <STRONG>Storage</STRONG> <STRONG>Format</STRONG>, and
- <STRONG>o</STRONG> <STRONG>EXTENDED</STRONG> <STRONG>STORAGE</STRONG> <STRONG>FORMAT</STRONG>, and
+ <STRONG>o</STRONG> <STRONG>Extended</STRONG> <STRONG>Storage</STRONG> <STRONG>Format</STRONG>, and
- <STRONG>o</STRONG> <STRONG>EXTENDED</STRONG> <STRONG>NUMBER</STRONG> <STRONG>FORMAT</STRONG>.
+ <STRONG>o</STRONG> <STRONG>Extended</STRONG> <STRONG>Number</STRONG> <STRONG>Format</STRONG>.
- The legacy storage format and the extended number format differ by the
- types of numeric capability which they can store (i.e., 16-bit versus
- 32-bit integers). The extended storage format introduced by <EM>ncurses</EM>
- 5.0 adds data to either of these formats.
+ The legacy storage format and the extended number format differ by the
+ types of numeric capability that they can store (for example, 16-
+ versus 32-bit integers). The extended storage format introduced by
+ <EM>ncurses</EM> 5.0 adds data to either of these formats.
Some limitations apply:
- <STRONG>o</STRONG> total compiled entries cannot exceed 4096 bytes in the legacy
+ <STRONG>o</STRONG> total compiled entries cannot exceed 4096 bytes in the legacy
format.
- <STRONG>o</STRONG> total compiled entries cannot exceed 32768 bytes in the extended
+ <STRONG>o</STRONG> total compiled entries cannot exceed 32768 bytes in the extended
format.
<STRONG>o</STRONG> the name field cannot exceed 128 bytes.
- Compiled entries are limited to 32768 bytes because offsets into the
- <EM>strings</EM> <EM>table</EM> use two-byte integers. The legacy format could have
- supported 32768-byte entries, but was limited to a virtual memory
+ Compiled entries are limited to 32768 bytes because offsets into the
+ <EM>strings</EM> <EM>table</EM> use two-byte integers. The legacy format could have
+ supported 32768-byte entries, but was limited to a virtual memory
page's 4096 bytes.
</PRE><H2><a name="h2-EXAMPLES">EXAMPLES</a></H2><PRE>
- As an example, here is a description for the Lear-Siegler ADM-3, a
- popular though rather stupid early terminal:
-
- adm3a|lsi adm3a,
- am,
- cols#80, lines#24,
- bel=^G, clear=\032$<1>, cr=^M, cub1=^H, cud1=^J,
- cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K,
- home=^^, ind=^J,
-
- and a hexadecimal dump of the compiled terminal description:
-
- 0000 1a 01 10 00 02 00 03 00 82 00 31 00 61 64 6d 33 ........ ..1.adm3
- 0010 61 7c 6c 73 69 20 61 64 6d 33 61 00 00 01 50 00 a|lsi ad m3a...P.
- 0020 ff ff 18 00 ff ff 00 00 02 00 ff ff ff ff 04 00 ........ ........
- 0030 ff ff ff ff ff ff ff ff 0a 00 25 00 27 00 ff ff ........ ..%.'...
- 0040 29 00 ff ff ff ff 2b 00 ff ff 2d 00 ff ff ff ff ).....+. ..-.....
- 0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 0090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 00a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 00b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 00c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 00d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 00e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 00f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 0100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 0110 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
- 0120 ff ff ff ff ff ff 2f 00 07 00 0d 00 1a 24 3c 31 ....../. .....$<1
- 0130 3e 00 1b 3d 25 70 31 25 7b 33 32 7d 25 2b 25 63 >..=%p1% {32}%+%c
- 0140 25 70 32 25 7b 33 32 7d 25 2b 25 63 00 0a 00 1e %p2%{32} %+%c....
- 0150 00 08 00 0c 00 0b 00 0a 00 ........ .
+ Here is a <EM>terminfo</EM> description of the Lear-Siegler ADM-3, a popular
+ though rather stupid early terminal.
+
+ adm3a|lsi adm3a,
+ am,
+ cols#80, lines#24,
+ bel=^G, clear=\032$<1>, cr=^M, cub1=^H, cud1=^J,
+ cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K,
+ home=^^, ind=^J,
+
+ A hexadecimal dump of its compiled terminal description (in legacy
+ format) follows.
+
+ 0000 1a 01 10 00 02 00 03 00 82 00 31 00 61 64 6d 33 ........ ..1.adm3
+ 0010 61 7c 6c 73 69 20 61 64 6d 33 61 00 00 01 50 00 a|lsi ad m3a...P.
+ 0020 ff ff 18 00 ff ff 00 00 02 00 ff ff ff ff 04 00 ........ ........
+ 0030 ff ff ff ff ff ff ff ff 0a 00 25 00 27 00 ff ff ........ ..%.'...
+ 0040 29 00 ff ff ff ff 2b 00 ff ff 2d 00 ff ff ff ff ).....+. ..-.....
+ 0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 0090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 00a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 00b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 00c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 00d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 00e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 00f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 0100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 0110 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
+ 0120 ff ff ff ff ff ff 2f 00 07 00 0d 00 1a 24 3c 31 ....../. .....$<1
+ 0130 3e 00 1b 3d 25 70 31 25 7b 33 32 7d 25 2b 25 63 >..=%p1% {32}%+%c
+ 0140 25 70 32 25 7b 33 32 7d 25 2b 25 63 00 0a 00 1e %p2%{32} %+%c....
+ 0150 00 08 00 0c 00 0b 00 0a 00 ........ .
</PRE><H2><a name="h2-AUTHORS">AUTHORS</a></H2><PRE>
Thomas E. Dickey
- extended terminfo format for <EM>ncurses</EM> 5.0
+ extended <EM>terminfo</EM> format for <EM>ncurses</EM> 5.0
hashed database support for <EM>ncurses</EM> 5.6
extended number support for <EM>ncurses</EM> 6.1
Eric S. Raymond
- documented legacy terminfo format, e.g., from <EM>pcurses</EM>.
+ documented legacy <EM>terminfo</EM> format (that used by <EM>pcurses</EM>).
</PRE><H2><a name="h2-SEE-ALSO">SEE ALSO</a></H2><PRE>
-ncurses 6.
4 2023-12-30 <STRONG><A HREF="term.5.html">term(5)</A></STRONG>
+ncurses 6.
5 2024-06-15 <STRONG><A HREF="term.5.html">term(5)</A></STRONG>
</PRE>
<div class="nav">
<ul>
<li><a href="#h2-NAME">NAME</a></li>
-<li><a href="#h2-SYNOPSIS">SYNOPSIS</a></li>
<li><a href="#h2-DESCRIPTION">DESCRIPTION</a>
<ul>
<li><a href="#h3-Storage-Location">Storage Location</a></li>
projects / ncurses.git / blobdiff