-</PRE><H3><a name="h3-Standards">Standards</a></H3><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.
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- implementations are not strictly compatible.
+ 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: