- 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:
-
- <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.
-
- <STRONG>o</STRONG> This implementation disallows matches by the termcap interface
- against extended capability names which are longer than two charac-
- ters.
-
- 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
- implementations) does not store terminal descriptions as text. It sets
- the buffer contents to a null-terminated string.
-
-
-</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.
-
- 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
- was written several years before C was standardized. However, there
- were two different termcap.h header files in the BSD sources:
-
- <STRONG>o</STRONG> One was used internally by the <STRONG>jove</STRONG> editor in 2BSD through 4.4BSD.
- 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.
+</PRE><H3><a name="h3-Standards">Standards</a></H3><PRE>
+ <STRONG>o</STRONG> X/Open Curses, Issue 4, Version 2 (1996), describes these
+ functions, marking them as "TO BE WITHDRAWN".
+
+ <STRONG>o</STRONG> X/Open Curses, Issue 7 (2009) marks the <EM>termcap</EM> interface (along
+ with <STRONG>vwprintw</STRONG> and <STRONG>vwscanw</STRONG>) as withdrawn.
+
+ Neither X/Open Curses nor the SVr4 man pages documented the return
+ values of <STRONG>tgetent</STRONG> correctly, though all three shown here were in fact
+ returned ever since SVr1. In particular, an omission in the X/Open
+ Curses specification 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 compatibility with the <EM>termcap</EM> library, that is a defect in
+ X/Open Curses, Issue 4, Version 2 rather than in <EM>ncurses</EM>.
+
+ <STRONG>Compatibility</STRONG> <STRONG>with</STRONG> <STRONG>BSD</STRONG> <EM>termcap</EM>
+ Externally visible variables are provided for support of certain
+ <EM>termcap</EM> applications. However, their correct usage is poorly
+ documented; for example, it is unclear when reading and writing them is
+ meaningful. In particular, some applications are reported to declare
+ and/or modify <STRONG>ospeed</STRONG>.
+
+ The constraint that only the first two characters of the <EM>id</EM> parameter
+ are used escapes many application developers. The BSD <EM>termcap</EM> library
+ did not require a trailing null character on the capability identifier
+ passed to <STRONG>tgetstr</STRONG>, <STRONG>tgetnum</STRONG>, and <STRONG>tgetflag</STRONG>. Some applications thus
+ assume that the <EM>termcap</EM> interface does not require the trailing null
+ character for the capability identifier.
+
+ <STRONG>o</STRONG> <EM>ncurses</EM> disallows matches by the <EM>termcap</EM> interface against extended
+ capability names that are longer than two characters; see
+ <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG>.
+
+ The BSD <EM>termcap</EM> function <STRONG>tgetent</STRONG> returns the text of a <EM>termcap</EM> entry in
+ the buffer passed as an argument. This library, like other <EM>terminfo</EM>
+ implementations, does not store terminal type descriptions as text. It
+ sets the buffer contents to a null-terminated string.
+
+
+</PRE><H3><a name="h3-Header-File">Header File</a></H3><PRE>
+ This library includes a <EM>termcap.h</EM> header for compatibility with other
+ implementations, but the header is rarely used because the other
+ implementations are not strictly compatible.
+
+
+</PRE><H2><a name="h2-HISTORY">HISTORY</a></H2><PRE>
+ Bill Joy originated a forerunner of <EM>termcap</EM> called "ttycap", dated
+ September 1977, and released in 1BSD (March 1978). It used many of the
+ same function names as the later <EM>termcap</EM>, such as <STRONG>tgetent</STRONG>, <STRONG>tgetflag</STRONG>,
+ <STRONG>tgetnum</STRONG>, and <STRONG>tgetstr</STRONG>.
+
+ A clear descendant, the <EM>termlib</EM> library, followed in 2BSD (May 1979),
+ adding <STRONG>tgoto</STRONG> and <STRONG>tputs</STRONG>. The former applied at that time only to cursor
+ positioning capabilities, thus the overly specific name. Little
+ changed in 3BSD (late 1979) except the addition of test programs and a
+ <EM>termlib</EM> man page, which documented the API shown in section "SYNOPSIS"
+ above.
+
+ 4BSD (November 1980) renamed <EM>termlib</EM> to <EM>termcap</EM> and added another test
+ program. The library remained much the same though 4.3BSD (June 1986).
+ 4.4BSD-Lite (June 1994) refactored it, leaving the API unchanged.
+
+ Function prototypes were a feature of ANSI C (1989). The library long
+ antedated the standard and thus provided no header file declaring them.
+ Nevertheless, the BSD sources included two different <EM>termcap.h</EM> header
+ files over time.
+
+ <STRONG>o</STRONG> One was used internally by <STRONG>jove(1)</STRONG> from 4.3BSD onward. It declared
+ global symbols for the <EM>termcap</EM> variables that it used.
+
+ <STRONG>o</STRONG> The other appeared in 4.4BSD-Lite Release 2 (June 1995) as part of
+ <EM>libedit</EM> (also known as the <EM>editline</EM> library). 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.
+ This header file was added to NetBSD's <EM>termcap</EM> library in mid-1994.
+
+ Meanwhile, GNU <EM>termcap</EM> began development in 1990. Its first release
+ (1.0) in 1991 included a <EM>termcap.h</EM> header. Its second (1.1) in
+ September 1992 modified the header to use <EM>const</EM> for the function
+ prototypes in the header where one would expect the parameters to be
+ read-only. BSD <EM>termcap</EM> did not. The prototype for <STRONG>tputs</STRONG> also
+ differed, but in that instance, it was <EM>libedit</EM> that differed from BSD
+ <EM>termcap</EM>.
+
+ GNU <EM>termcap</EM> 1.3 was bundled with <STRONG>bash(1)</STRONG> in mid-1993 to support the
+ <STRONG>readline(3)</STRONG> library.
+
+ <EM>ncurses</EM> 1.8.1 (November 1993) provided a <EM>termcap.h</EM> file. It reflected
+ influence from GNU <EM>termcap</EM> and <STRONG>emacs(1)</STRONG> (rather than <STRONG>jove(1)</STRONG>),
+ providing the following interface:
+
+ <STRONG>o</STRONG> global symbols used by <EM>emacs</EM>,
+
+ <STRONG>o</STRONG> <EM>const</EM>-qualified function prototypes, and
+
+ <STRONG>o</STRONG> a prototype for <STRONG>tparam</STRONG>, a GNU <EM>termcap</EM> feature.
+
+ Later (in mid-1996) the <STRONG>tparam</STRONG> function was removed from <EM>ncurses</EM>. Any
+ two of the four implementations thus differ, and programs that intend
+ to work with all <EM>termcap</EM> library interfaces must account for that fact.