- This implementation of <STRONG>tput</STRONG> differs from AT&T <STRONG>tput</STRONG> in two
- important areas:
-
- <STRONG>o</STRONG> <STRONG>tput</STRONG> <EM>capname</EM> writes to the standard output. That need
- not be a regular terminal. However, the subcommands
- which manipulate terminal modes may not use the stan-
- dard output.
-
- The AT&T implementation's <STRONG>init</STRONG> and <STRONG>reset</STRONG> commands use
- the BSD (4.1c) <STRONG>tset</STRONG> source, which manipulates terminal
- modes. It successively tries standard output, stan-
- dard error, standard input before falling back to
- "/dev/tty" and finally just assumes a 1200Bd terminal.
- When updating terminal modes, it ignores errors.
-
- Until changes made after ncurses 6.0, <STRONG>tput</STRONG> did not
- modify terminal modes. <STRONG>tput</STRONG> now uses a similar
- scheme, using functions shared with <STRONG>tset</STRONG> (and ulti-
- mately based on the 4.4BSD <STRONG>tset</STRONG>). If it is not able
- to open a terminal, e.g., when running in <STRONG>cron</STRONG>, <STRONG>tput</STRONG>
- will return an error.
-
- <STRONG>o</STRONG> AT&T <STRONG>tput</STRONG> guesses the type of its <EM>capname</EM> operands by
- seeing if all of the characters are numeric, or not.
-
- Most implementations which provide support for <EM>capname</EM>
- operands use the <EM>tparm</EM> function to expand parameters
- in it. That function expects a mixture of numeric and
- string parameters, requiring <STRONG>tput</STRONG> to know which type
- to use.
-
- This implementation uses a table to determine the
- parameter types for the standard <EM>capname</EM> operands, and
- an internal library function to analyze nonstandard
- <EM>capname</EM> operands.
-
- This implementation (unlike others) can accept both <EM>term-</EM>
- <EM>cap</EM> and <EM>terminfo</EM> names for the <EM>capname</EM> feature, if <EM>termcap</EM>
- support is compiled in. However, the predefined <EM>termcap</EM>
- and <EM>terminfo</EM> names have two ambiguities in this case (and
- the <EM>terminfo</EM> name is assumed):
-
- <STRONG>o</STRONG> The <EM>termcap</EM> name <STRONG>dl</STRONG> corresponds to the <EM>terminfo</EM> name
- <STRONG>dl1</STRONG> (delete one line).
- The <EM>terminfo</EM> name <STRONG>dl</STRONG> corresponds to the <EM>termcap</EM> name
- <STRONG>DL</STRONG> (delete a given number of lines).
-
- <STRONG>o</STRONG> The <EM>termcap</EM> name <STRONG>ed</STRONG> corresponds to the <EM>terminfo</EM> name
- <STRONG>rmdc</STRONG> (end delete mode).
- The <EM>terminfo</EM> name <STRONG>ed</STRONG> corresponds to the <EM>termcap</EM> name
- <STRONG>cd</STRONG> (clear to end of screen).
-
- The <STRONG>longname</STRONG> and <STRONG>-S</STRONG> options, and the parameter-substitu-
- tion features used in the <STRONG>cup</STRONG> example, were not supported
- in BSD curses before 4.3reno (1989) or in AT&T/USL curses
- before SVr4 (1988).
-
- IEEE Std 1003.1/The Open Group Base Specifications Issue
- 7 (POSIX.1-2008) documents only the operands for <STRONG>clear</STRONG>,
- <STRONG>init</STRONG> and <STRONG>reset</STRONG>. There are a few interesting observations
- to make regarding that:
-
- <STRONG>o</STRONG> In this implementation, <STRONG>clear</STRONG> is part of the <EM>capname</EM>
- support. The others (<STRONG>init</STRONG> and <STRONG>longname</STRONG>) do not corre-
- spond to terminal capabilities.
-
- <STRONG>o</STRONG> Other implementations of <STRONG>tput</STRONG> on SVr4-based systems
- such as Solaris, IRIX64 and HPUX as well as others
- such as AIX and Tru64 provide support for <EM>capname</EM> op-
- erands.
-
- <STRONG>o</STRONG> A few platforms such as FreeBSD recognize termcap
- names rather than terminfo capability names in their
- respective <STRONG>tput</STRONG> commands. Since 2010, NetBSD's <STRONG>tput</STRONG>
- uses terminfo names. Before that, it (like FreeBSD)
- recognized termcap names.
-
- Because (apparently) <EM>all</EM> of the certified Unix systems
- support the full set of capability names, the reasoning
- for documenting only a few may not be apparent.
-
- <STRONG>o</STRONG> X/Open Curses Issue 7 documents <STRONG>tput</STRONG> differently, with
- <EM>capname</EM> and the other features used in this implemen-
- tation.
-
- <STRONG>o</STRONG> That is, there are two standards for <STRONG>tput</STRONG>: POSIX (a
- subset) and X/Open Curses (the full implementation).
- POSIX documents a subset to avoid the complication of
- including X/Open Curses and the terminal capabilities
- database.
-
- <STRONG>o</STRONG> While it is certainly possible to write a <STRONG>tput</STRONG> program
- without using curses, none of the systems which have a
- curses implementation provide a <STRONG>tput</STRONG> utility which
- does not provide the <EM>capname</EM> feature.
+ This implementation of <STRONG>tput</STRONG> differs from AT&T <STRONG>tput</STRONG> in two important
+ areas:
+
+ <STRONG>o</STRONG> <STRONG>tput</STRONG> <EM>capname</EM> writes to the standard output. That need not be a
+ regular terminal. However, the subcommands which manipulate
+ terminal modes may not use the standard output.
+
+ The AT&T implementation's <STRONG>init</STRONG> and <STRONG>reset</STRONG> commands use the BSD
+ (4.1c) <STRONG>tset</STRONG> source, which manipulates terminal modes. It
+ successively tries standard output, standard error, standard input
+ before falling back to "/dev/tty" and finally just assumes a 1200Bd
+ terminal. When updating terminal modes, it ignores errors.
+
+ Until changes made after ncurses 6.0, <STRONG>tput</STRONG> did not modify terminal
+ modes. <STRONG>tput</STRONG> now uses a similar scheme, using functions shared with
+ <STRONG>tset</STRONG> (and ultimately based on the 4.4BSD <STRONG>tset</STRONG>). If it is not able
+ to open a terminal, e.g., when running in <STRONG>cron(1)</STRONG>, <STRONG>tput</STRONG> will return
+ an error.
+
+ <STRONG>o</STRONG> AT&T <STRONG>tput</STRONG> guesses the type of its <EM>capname</EM> operands by seeing if all
+ of the characters are numeric, or not.
+
+ Most implementations which provide support for <EM>capname</EM> operands use
+ the <STRONG>tparm</STRONG> function to expand parameters in it. That function
+ expects a mixture of numeric and string parameters, requiring <STRONG>tput</STRONG>
+ to know which type to use.
+
+ This implementation uses a table to determine the parameter types
+ for the standard <EM>capname</EM> operands, and an internal library function
+ to analyze nonstandard <EM>capname</EM> operands.
+
+ Besides providing more reliable operation than AT&T's utility, a
+ portability problem is introduced by this analysis: An OpenBSD
+ developer adapted the internal library function from ncurses to
+ port NetBSD's termcap-based <STRONG>tput</STRONG> to terminfo. That had been
+ modified to interpret multiple commands on a line. Portable
+ applications should not rely upon this feature; ncurses provides it
+ to support applications written specifically for OpenBSD.
+
+ This implementation (unlike others) can accept both <EM>termcap</EM> and
+ <EM>terminfo</EM> names for the <EM>capname</EM> feature, if <EM>termcap</EM> support is compiled
+ in. However, the predefined <EM>termcap</EM> and <EM>terminfo</EM> names have two
+ ambiguities in this case (and the <EM>terminfo</EM> name is assumed):
+
+ <STRONG>o</STRONG> The <EM>termcap</EM> name <STRONG>dl</STRONG> corresponds to the <EM>terminfo</EM> name <STRONG>dl1</STRONG> (delete
+ one line).
+ The <EM>terminfo</EM> name <STRONG>dl</STRONG> corresponds to the <EM>termcap</EM> name <STRONG>DL</STRONG> (delete a
+ given number of lines).
+
+ <STRONG>o</STRONG> The <EM>termcap</EM> name <STRONG>ed</STRONG> corresponds to the <EM>terminfo</EM> name <STRONG>rmdc</STRONG> (end
+ delete mode).
+ The <EM>terminfo</EM> name <STRONG>ed</STRONG> corresponds to the <EM>termcap</EM> name <STRONG>cd</STRONG> (clear to
+ end of screen).
+
+ The <STRONG>longname</STRONG> and <STRONG>-S</STRONG> options, and the parameter-substitution features
+ used in the <STRONG>cup</STRONG> example, were not supported in BSD curses before
+ 4.3reno (1989) or in AT&T/USL curses before SVr4 (1988).
+
+ IEEE Std 1003.1/The Open Group Base Specifications Issue 7
+ (POSIX.1-2008) documents only the operands for <STRONG>clear</STRONG>, <STRONG>init</STRONG> and <STRONG>reset</STRONG>.
+ There are a few interesting observations to make regarding that:
+
+ <STRONG>o</STRONG> In this implementation, <STRONG>clear</STRONG> is part of the <EM>capname</EM> support. The
+ others (<STRONG>init</STRONG> and <STRONG>longname</STRONG>) do not correspond to terminal
+ capabilities.
+
+ <STRONG>o</STRONG> Other implementations of <STRONG>tput</STRONG> on SVr4-based systems such as
+ Solaris, IRIX64 and HPUX as well as others such as AIX and Tru64
+ provide support for <EM>capname</EM> operands.
+
+ <STRONG>o</STRONG> A few platforms such as FreeBSD recognize termcap names rather than
+ terminfo capability names in their respective <STRONG>tput</STRONG> commands. Since
+ 2010, NetBSD's <STRONG>tput</STRONG> uses terminfo names. Before that, it (like
+ FreeBSD) recognized termcap names.
+
+ Beginning in 2021, FreeBSD uses the ncurses <STRONG>tput</STRONG>, configured for
+ both terminfo (tested first) and termcap (as a fallback).
+
+ Because (apparently) <EM>all</EM> of the certified Unix systems support the full
+ set of capability names, the reasoning for documenting only a few may
+ not be apparent.
+
+ <STRONG>o</STRONG> X/Open Curses Issue 7 documents <STRONG>tput</STRONG> differently, with <EM>capname</EM> and
+ the other features used in this implementation.
+
+ <STRONG>o</STRONG> That is, there are two standards for <STRONG>tput</STRONG>: POSIX (a subset) and
+ X/Open Curses (the full implementation). POSIX documents a subset
+ to avoid the complication of including X/Open Curses and the
+ terminal capabilities database.
+
+ <STRONG>o</STRONG> While it is certainly possible to write a <STRONG>tput</STRONG> program without
+ using curses, none of the systems which have a curses
+ implementation provide a <STRONG>tput</STRONG> utility which does not provide the
+ <EM>capname</EM> feature.
+
+ X/Open Curses Issue 7 (2009) is the first version to document
+ utilities. However that part of X/Open Curses does not follow existing
+ practice (i.e., Unix features documented in SVID 3):
+
+ <STRONG>o</STRONG> It assigns exit code 4 to "invalid operand", which may be the same
+ as <EM>unknown</EM> <EM>capability</EM>. For instance, the source code for Solaris'
+ xcurses uses the term "invalid" in this case.
+
+ <STRONG>o</STRONG> It assigns exit code 255 to a numeric variable that is not
+ specified in the terminfo database. That likely is a documentation
+ error, confusing the <STRONG>-1</STRONG> written to the standard output for an
+ absent or cancelled numeric value versus an (unsigned) exit code.
+
+ The various Unix systems (AIX, HPUX, Solaris) use the same exit-codes
+ as ncurses.
+
+ NetBSD curses documents different exit codes which do not correspond to
+ either ncurses or X/Open.