* sale, use or other dealings in this Software without prior written *
* authorization. *
****************************************************************************
- * @Id: curs_termcap.3x,v 1.62 2023/07/01 15:28:47 tom Exp @
+ * @Id: curs_termcap.3x,v 1.66 2023/09/16 23:37:03 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>curs_termcap 3x 2023-07-01 ncurses 6.4 Library calls</TITLE>
+<TITLE>curs_termcap 3x 2023-09-16 ncurses 6.4 Library calls</TITLE>
<link rel="author" href="mailto:bug-ncurses@gnu.org">
</HEAD>
<BODY>
-<H1 class="no-header">curs_termcap 3x 2023-07-01 ncurses 6.4 Library calls</H1>
+<H1 class="no-header">curs_termcap 3x 2023-09-16 ncurses 6.4 Library calls</H1>
<PRE>
<STRONG><A HREF="curs_termcap.3x.html">curs_termcap(3x)</A></STRONG> Library calls <STRONG><A HREF="curs_termcap.3x.html">curs_termcap(3x)</A></STRONG>
</PRE><H2><a name="h2-NAME">NAME</a></H2><PRE>
<STRONG>PC</STRONG>, <STRONG>UP</STRONG>, <STRONG>BC</STRONG>, <STRONG>ospeed</STRONG>, <STRONG>tgetent</STRONG>, <STRONG>tgetflag</STRONG>, <STRONG>tgetnum</STRONG>, <STRONG>tgetstr</STRONG>, <STRONG>tgoto</STRONG>, <STRONG>tputs</STRONG> -
- <STRONG>curses</STRONG> emulation of termcap
+ <EM>curses</EM> emulation of <EM>termcap</EM>
</PRE><H2><a name="h2-SYNOPSIS">SYNOPSIS</a></H2><PRE>
This differs from the <EM>termcap</EM> library in two ways:
- <STRONG>o</STRONG> The emulation ignores the buffer pointer <EM>bp</EM>. The <EM>termcap</EM> li-
- brary would store a copy of the terminal description in the area
- referenced by this pointer. However, ncurses stores its termi-
- nal descriptions in compiled binary form, which is not the same
- thing.
+ <STRONG>o</STRONG> The emulation ignores the buffer pointer <EM>bp</EM>. The <EM>termcap</EM>
+ library would store a copy of the terminal description in the
+ area referenced by this pointer. However, ncurses stores its
+ terminal descriptions in compiled binary form, which is not the
+ same thing.
<STRONG>o</STRONG> There is a difference in return codes. The <EM>termcap</EM> library does
not check if the terminal description is marked with the <EM>generic</EM>
- capability, or if the terminal description has cursor-address-
- ing.
+ capability, or if the terminal description has cursor-
+ addressing.
</PRE><H3><a name="h3-Capability-Values">Capability Values</a></H3><PRE>
available.
The <STRONG>tgetstr</STRONG> routine returns the string entry for <EM>id</EM>, or zero if it is
- not available. Use <STRONG>tputs</STRONG> to output the returned string. The <EM>area</EM> pa-
- rameter is used as follows:
+ not available. Use <STRONG>tputs</STRONG> to output the returned string. The <EM>area</EM>
+ parameter is used as follows:
<STRONG>o</STRONG> It is assumed to be the address of a pointer to a buffer managed
by the calling application.
- <STRONG>o</STRONG> However, ncurses checks to ensure that <STRONG>area</STRONG> is not NULL, and al-
- so that the resulting buffer pointer is not NULL. If either
+ <STRONG>o</STRONG> However, ncurses checks to ensure that <STRONG>area</STRONG> is not NULL, and
+ also that the resulting buffer pointer is not NULL. If either
check fails, the <EM>area</EM> parameter is ignored.
<STRONG>o</STRONG> If the checks succeed, ncurses also copies the return value to
- the buffer pointed to by <EM>area</EM>, and the <EM>area</EM> value will be updat-
- ed to point past the null ending this value.
+ the buffer pointed to by <EM>area</EM>, and the <EM>area</EM> value will be
+ updated to point past the null ending this value.
- <STRONG>o</STRONG> The return value itself is an address in the terminal descrip-
- tion which is loaded into memory.
+ <STRONG>o</STRONG> The return value itself is an address in the terminal
+ description which is loaded into memory.
Only the first two characters of the <STRONG>id</STRONG> parameter of <STRONG>tgetflag</STRONG>, <STRONG>tgetnum</STRONG>
and <STRONG>tgetstr</STRONG> are compared in lookups.
The <STRONG>tgoto</STRONG> routine expands the given capability using the parameters.
<STRONG>o</STRONG> Because the capability may have padding characters, the output of
- <STRONG>tgoto</STRONG> should be passed to <STRONG>tputs</STRONG> rather than some other output func-
- tion such as <STRONG>printf(3)</STRONG>.
+ <STRONG>tgoto</STRONG> should be passed to <STRONG>tputs</STRONG> rather than some other output
+ function such as <STRONG>printf(3)</STRONG>.
- <STRONG>o</STRONG> While <STRONG>tgoto</STRONG> is assumed to be used for the two-parameter cursor po-
- sitioning capability, termcap applications also use it for single-
- parameter capabilities.
+ <STRONG>o</STRONG> While <STRONG>tgoto</STRONG> is assumed to be used for the two-parameter cursor
+ positioning capability, termcap applications also use it for
+ single-parameter capabilities.
- Doing this shows a quirk in <STRONG>tgoto</STRONG>: most hardware terminals use cur-
- sor addressing with <EM>row</EM> first, but the original developers of the
- termcap interface chose to put the <EM>column</EM> parameter first. The
+ Doing this shows a quirk in <STRONG>tgoto</STRONG>: most hardware terminals use
+ cursor addressing with <EM>row</EM> first, but the original developers of
+ the termcap interface chose to put the <EM>column</EM> parameter first. The
<STRONG>tgoto</STRONG> function swaps the order of parameters. It does this also
for calls requiring only a single parameter. In that case, the
first parameter is merely a placeholder.
<STRONG>o</STRONG> Normally the ncurses library is compiled with terminfo support. In
- that case, <STRONG>tgoto</STRONG> uses an internal version of <STRONG><A HREF="curs_terminfo.3x.html">tparm(3x)</A></STRONG> (a more ca-
- pable formatter).
+ that case, <STRONG>tgoto</STRONG> uses an internal version of <STRONG><A HREF="curs_terminfo.3x.html">tparm(3x)</A></STRONG> (a more
+ capable formatter).
With terminfo support, <STRONG>tgoto</STRONG> is able to use some of the terminfo
- features, but not all. In particular, it allows only numeric pa-
- rameters; <STRONG>tparm</STRONG> supports string parameters.
+ features, but not all. In particular, it allows only numeric
+ parameters; <STRONG>tparm</STRONG> supports string parameters.
- However, <STRONG>tparm</STRONG> is not a <EM>termcap</EM> feature, and portable <EM>termcap</EM> ap-
- plications should not rely upon its availability.
+ However, <STRONG>tparm</STRONG> is not a <EM>termcap</EM> feature, and portable <EM>termcap</EM>
+ applications should not rely upon its availability.
The <STRONG>tputs</STRONG> routine is described on the <STRONG><A HREF="curs_terminfo.3x.html">curs_terminfo(3x)</A></STRONG> manual page.
It can retrieve capabilities by either termcap or terminfo name.
</PRE><H3><a name="h3-Releasing-Memory">Releasing Memory</a></H3><PRE>
The termcap functions provide no means for freeing memory, because
legacy termcap implementations used only the buffer areas provided by
- the caller via <STRONG>tgetent</STRONG> and <STRONG>tgetstr</STRONG>. Those buffers are unused in ter-
- minfo.
+ the caller via <STRONG>tgetent</STRONG> and <STRONG>tgetstr</STRONG>. Those buffers are unused in
+ terminfo.
- On the other hand, terminfo allocates memory. It uses <STRONG>setupterm</STRONG> to re-
- trieve the data used by <STRONG>tgetent</STRONG> and the functions which return capabil-
- ity values such as <STRONG>tgetstr</STRONG>. One could use
+ On the other hand, terminfo allocates memory. It uses <STRONG>setupterm</STRONG> to
+ retrieve the data used by <STRONG>tgetent</STRONG> and the functions which return
+ capability values such as <STRONG>tgetstr</STRONG>. One could use
<STRONG>del_curterm(cur_term);</STRONG>
to free this memory, but there is an additional complication with
- ncurses. It uses a fixed-size <EM>pool</EM> of storage locations, one per set-
- ting of the <STRONG>TERM</STRONG> variable when <STRONG>tgetent</STRONG> is called. The <STRONG>screen(1)</STRONG> pro-
- gram relies upon this arrangement, to improve its performance.
+ ncurses. It uses a fixed-size <EM>pool</EM> of storage locations, one per
+ setting of the <STRONG>TERM</STRONG> variable when <STRONG>tgetent</STRONG> is called. The <STRONG>screen(1)</STRONG>
+ program relies upon this arrangement, to improve its performance.
An application which uses only the low-level termcap functions could
- free the memory using <STRONG>del_curterm</STRONG>, because the pool is freed using oth-
- er functions (see <STRONG><A HREF="curs_memleaks.3x.html">curs_memleaks(3x)</A></STRONG>).
+ free the memory using <STRONG>del_curterm</STRONG>, because the pool is freed using
+
other functions (see <STRONG><A HREF="curs_memleaks.3x.html">curs_memleaks(3x)</A></STRONG>).
</PRE><H2><a name="h2-RETURN-VALUE">RETURN VALUE</a></H2><PRE>
<STRONG>o</STRONG> The calls with a string parameter (<STRONG>tgoto</STRONG>, <STRONG>tputs</STRONG>) check if the
string is null, or cancelled. Those return an error.
- <STRONG>o</STRONG> A call to <STRONG>tgoto</STRONG> using a capability with string parameters is an er-
- ror.
+ <STRONG>o</STRONG> A call to <STRONG>tgoto</STRONG> using a capability with string parameters is an
+ error.
<STRONG>o</STRONG> A call to <STRONG>tgoto</STRONG> using a capability with more than two parameters is
an error.
aware that it will be returned in terminfo notation, not the older and
not-quite-compatible termcap notation. This will not cause problems if
all you do with it is call <STRONG>tgoto</STRONG> or <STRONG>tparm</STRONG>, which both expand terminfo-
- style strings as terminfo. (The <STRONG>tgoto</STRONG> function, if configured to sup-
- port termcap, will check if the string is indeed terminfo-style by
+ style strings as terminfo. (The <STRONG>tgoto</STRONG> function, if configured to
+ support termcap, will check if the string is indeed terminfo-style by
looking for "%p" parameters or "$<..>" delays, and invoke a termcap-
style parser if the string does not appear to be terminfo).
- Because terminfo conventions for representing padding in string capa-
- bilities differ from termcap's, users can be surprised:
+ Because terminfo conventions for representing padding in string
+ capabilities differ from termcap's, users can be surprised:
<STRONG>o</STRONG> <STRONG>tputs("50")</STRONG> in a terminfo system will put out a literal "50" rather
than busy-waiting for 50 milliseconds.
<STRONG>o</STRONG> However, if ncurses is configured to support termcap, it may also
have been configured to support the BSD-style padding.
- In that case, <STRONG>tputs</STRONG> inspects strings passed to it, looking for dig-
- its at the beginning of the string.
+ In that case, <STRONG>tputs</STRONG> inspects strings passed to it, looking for
+ digits at the beginning of the string.
<STRONG>tputs("50")</STRONG> in a termcap system may wait for 50 milliseconds rather
than put out a literal "50"
Note that termcap has nothing analogous to terminfo's <STRONG>sgr</STRONG> string. One
consequence of this is that termcap applications assume <STRONG>me</STRONG> (terminfo
<STRONG>sgr0</STRONG>) does not reset the alternate character set. This implementation
- checks for, and modifies the data shown to the termcap interface to ac-
- commodate termcap's limitation in this respect.
+ checks for, and modifies the data shown to the termcap interface to
+ accommodate termcap's limitation in this respect.
</PRE><H2><a name="h2-PORTABILITY">PORTABILITY</a></H2><PRE>
These functions are provided for supporting legacy applications, and
should not be used in new programs:
- <STRONG>o</STRONG> The XSI Curses standard, Issue 4 describes these functions. Howev-
- er, they are marked TO BE WITHDRAWN and may be removed in future
- versions.
+ <STRONG>o</STRONG> The XSI Curses standard, Issue 4 describes these functions.
+ However, they are marked TO BE WITHDRAWN and may be removed in
+ future versions.
<STRONG>o</STRONG> X/Open Curses, Issue 5 (December 2007) marked the termcap interface
(along with <STRONG>vwprintw</STRONG> and <STRONG>vwscanw</STRONG>) as withdrawn.
Neither the XSI Curses standard nor the SVr4 man pages documented the
- return values of <STRONG>tgetent</STRONG> correctly, though all three were in fact re-
- turned ever since SVr1. In particular, an omission in the XSI Curses
+ return values of <STRONG>tgetent</STRONG> correctly, though all three were in fact
+ returned ever since SVr1. In particular, an omission in the XSI Curses
documentation has been misinterpreted to mean that <STRONG>tgetent</STRONG> returns <STRONG>OK</STRONG>
- or <STRONG>ERR</STRONG>. Because the purpose of these functions is to provide compati-
- bility with the <EM>termcap</EM> library, that is a defect in XCurses, Issue 4,
- Version 2 rather than in ncurses.
+ or <STRONG>ERR</STRONG>. Because the purpose of these functions is to provide
+ compatibility with the <EM>termcap</EM> library, that is a defect in XCurses,
+ Issue 4, Version 2 rather than in ncurses.
</PRE><H3><a name="h3-Compatibility-with-BSD-Termcap">Compatibility with BSD Termcap</a></H3><PRE>
- External variables are provided for support of certain termcap applica-
- tions. However, termcap applications' use of those variables is poorly
- documented, e.g., not distinguishing between input and output. In par-
- ticular, some applications are reported to declare and/or modify <STRONG>os-</STRONG>
- <STRONG>peed</STRONG>.
+ External variables are provided for support of certain termcap
+ applications. However, termcap applications' use of those variables is
+ poorly documented, e.g., not distinguishing between input and output.
+ In particular, some applications are reported to declare and/or modify
+ <STRONG>ospeed</STRONG>.
The comment that only the first two characters of the <STRONG>id</STRONG> parameter are
used escapes many application developers. The original BSD 4.2 termcap
library (and historical relics thereof) did not require a trailing null
NUL on the parameter name passed to <STRONG>tgetstr</STRONG>, <STRONG>tgetnum</STRONG> and <STRONG>tgetflag</STRONG>.
Some applications assume that the termcap interface does not require
- the trailing NUL for the parameter name. Taking into account these is-
- sues:
+ the trailing NUL for the parameter name. Taking into account these
+ issues:
<STRONG>o</STRONG> As a special case, <STRONG>tgetflag</STRONG> matched against a single-character
- identifier provided that was at the end of the terminal descrip-
- tion. You should not rely upon this behavior in portable programs.
- This implementation disallows matches against single-character ca-
- pability names.
+ identifier provided that was at the end of the terminal
+ description. You should not rely upon this behavior in portable
+ programs. This implementation disallows matches against single-
+ character capability names.
<STRONG>o</STRONG> This implementation disallows matches by the termcap interface
- against extended capability names which are longer than two charac-
- ters.
+ against extended capability names which are longer than two
+ characters.
The BSD termcap function <STRONG>tgetent</STRONG> returns the text of a termcap entry in
the buffer passed as an argument. This library (like other terminfo
</PRE><H3><a name="h3-Other-Compatibility">Other Compatibility</a></H3><PRE>
This library includes a termcap.h header, for compatibility with other
- implementations. But the header is rarely used because the other im-
- plementations are not strictly compatible.
+ implementations. But the header is rarely used because the other
+ implementations are not strictly compatible.
The original BSD termcap (through 4.3BSD) had no header file which gave
function prototypes, because that was a feature of ANSI C. BSD termcap
It defined global symbols for the termcap variables which it used.
<STRONG>o</STRONG> The other appeared in 4.4BSD Lite Release 2 (mid-1993) as part of
- <EM>libedit</EM> (also known as the <EM>editline</EM> library). The CSRG source his-
- tory shows that this was added in mid-1992. The <EM>libedit</EM> header
- file was used internally, as a convenience for compiling the <EM>edit-</EM>
- <EM>line</EM> library. It declared function prototypes, but no global vari-
- ables.
+ <EM>libedit</EM> (also known as the <EM>editline</EM> library). The CSRG source
+ history shows that this was added in mid-1992. The <EM>libedit</EM> header
+ file was used internally, as a convenience for compiling the
+ <EM>editline</EM> library. It declared function prototypes, but no global
+ variables.
The header file from <EM>libedit</EM> was added to NetBSD's termcap library in
mid-1994.
Meanwhile, GNU termcap was under development, starting in 1990. The
first release (termcap 1.0) in 1991 included a termcap.h header. The
second release (termcap 1.1) in September 1992 modified the header to
- use <STRONG>const</STRONG> for the function prototypes in the header where one would ex-
- pect the parameters to be read-only. This was a difference versus the
- original BSD termcap. The prototype for <STRONG>tputs</STRONG> also differed, but in
- that instance, it was <EM>libedit</EM> which differed from BSD termcap.
+ use <STRONG>const</STRONG> for the function prototypes in the header where one would
+ expect the parameters to be read-only. This was a difference versus
+ the original BSD termcap. The prototype for <STRONG>tputs</STRONG> also differed, but
+ in that instance, it was <EM>libedit</EM> which differed from BSD termcap.
A copy of GNU termcap 1.3 was bundled with <EM>bash</EM> in mid-1993, to support
the <STRONG>readline(3)</STRONG> library.
-ncurses 6.4 2023-0
7-01 <STRONG><A HREF="curs_termcap.3x.html">curs_termcap(3x)</A></STRONG>
+ncurses 6.4 2023-0
9-16 <STRONG><A HREF="curs_termcap.3x.html">curs_termcap(3x)</A></STRONG>
</PRE>
<div class="nav">
<ul>
projects / ncurses.git / blobdiff