POSIX terminal interface: Difference between revisions

The '''POSIX terminal interface''' is the generalized abstraction, comprising both an [[Applicationapplication Programmingprogramming Interfaceinterface]] for programs, and a set of behavioural expectations for users of a [[terminal (telecommunication)|terminal]], as defined by the [[POSIX]] standard and the [[Single Unix Specification]]. It is a historical development from the terminal interfaces of BSD version 4 and [[Seventh Edition Unix]].

* [[serial device]]s connected by a [[serial port]] such as [[printer (computing)|printer]]s/[[teleprinter]]s, [[teletypewriter]]s, [[modem]]s supporting ''remote'' [[terminal (telecommunication)|terminal]]s via [[dial-up access]], and directly- connected ''local'' terminals{{sfn|Christian|1988|p=11}}{{sfn|Coffin|1991|p=820}}{{sfn|Coffin|1991|p=23–24}}{{sfn|Leffler|McKusick|Karels|Quarterman|1989|p=259}}

* software [[terminal emulator]]s, such as the [[xterm]], [[Konsole]], [[GNOME Terminal]], and [[Terminal (OS XmacOS)|Terminal]] programs, and network servers such as the [[rlogin]] daemon and the [[Secure Shell|SSH]] daemon, which make use of [[pseudoterminal]]s

The "capabilities" of a terminal comprise various dumb terminal features that are above and beyond what is available from a pure teletypewriter, which programs can make use of. They (mainly) comprise escape codes that can be sent to or received from the terminal. The escape codes sent to the terminal perform various functions that a CRT terminal (or software terminal emulator) is capable of that a teletypewriter is not, such as moving the terminal's cursor to positions on the screen, clearing and scrolling all or parts of the screen, turning on and off attached printer devices, programmable function keys, changing display colours and attributes (such as [[reverse video]]), and setting display title strings. The escape codes received from the terminal signify things such as [[function key]], [[arrow key]], and other special [[Typing|keystroke]]s ([[home key]], [[end key]], [[help key]], [[PgUp key]], [[PgDn key]], [[insert key]], [[delete key]], and so forth).{{sfn|Afzal|2008|p=419}}{{sfn|Frisch|2002|p=770}}

These capabilities are encoded in databases that are configured by a system administrator and accessed from programs via the [[terminfo]] library (which supersedes the older [[termcap]] library), upon which in turn are built libraries such as the [[curses (programming library)|curses]] and [[ncurses]] libraries. Application programs use the terminal capabilities to provide [[textual user interface]]s with windows, dialogue boxes, buttons, labels, input fields, menus, and so forth.{{sfn|Coffin|1991|p=115}}{{sfn|Coffin|1991|p=372}}

The particular set of capabilities for the terminal that a (terminal-aware) program's input and output uses is obtained from the database rather than hardwired into programs and libraries, and is controlled by the <code>TERM</code> [[environment variable]] (and, optionally for the termcap libraryand terminfo libraries, the <code>TERMCAP</code> environment variable), and, optionally for the terminfo library, the <code>TERMINFO</code> environment variablevariables, respectively).{{sfn|Coffin|1991|p=115}} This variable is set by whatever ''terminal monitor'' program spawns the programs that then use that terminal for its input and output, or sometimes explicitly. For example:

* The software terminal emulator, using a pseudoterminal, sets the <code>TERM</code> environment variable to specify the type of terminal that it is emulating. Emulated terminals often do not exactly match real terminal hardware, and terminal emulators have type names dedicated for their use. The xterm program (by default) sets <code>xterm</code> as the terminal type, for example.{{sfn|Coffin|1991|p=751&ndash;752}} The screen[[GNU Screen]] program sets <code>screen</code> as the terminal type.

Strictly speaking, in UnicesUnixes a terminal device comprises the underlying ''tty device driver'', responsible for the physical control of the device hardware via I/O instructions and handling device interrupt requests for character input and output, and the ''line discipline''. A line discipline is independent of the actual device hardware, and the same line discipline can be used for a [[terminal concentrator]] device responsible for multiple controlling terminals as for a pseudoterminal. In fact, the line discipline (or, in the case of BSD, AIX, and other systems, line ''disciplines'') are the same across all terminal devices. It is the line discipline that is responsible for local echo, line editing, processing of input modes, processing of output modes, and character mapping. All these things are independent of the actual hardware, dealing as they do in the simple abstractions provided by tty device drivers: transmit a character, receive a character, set various hardware states.{{sfn|Leffler|McKusick|Karels|Quarterman|1989|p=38}}{{sfn|Leffler|McKusick|Karels|Quarterman|1989|p=260&ndash;261}}

In [[Seventh Edition Unix]], [[BSD]] systems and derivatives including [[OS XmacOS]], and [[Linux]], each terminal device can be switched amongst multiple line disciplines.{{sfn|Leffler|McKusick|Karels|Quarterman|1989|p=262}} In the AT&amp;T [[STREAMS]] system, line disciplines are STREAMS modules that may be pushed onto and popped off a STREAMS I/O stack.{{sfn|Christian|1988|p=395}}

=== Early UnicesUnixes: Seventh Edition Unix ===

The terminal interface provided by Unix 32V and Seventh Edition Unix, and also presented by BSD version 4 as the ''old terminal driver'', was a simple one, largely geared towards teletypewriters as terminals. Input was entered a line at a time, with the terminal driver in the operating system (and not the terminals themselves) providing simple line editing capabilities. A buffer was maintained by the kernel in which editing took place. Applications reading terminal input would receive the contents of the buffer only when the {{keypress|return}} key was pressed on the terminal to end line editing. The {{keypress|@}} key sent from the terminal to the system would erase ("kill") the entire current contents of the editing buffer, and would be normally displayed as an '<tt>{{mono|@</tt>}}' symbol followed by a newline sequence to move the print position to a fresh blank line. The {{keypress|#}} key sent from the terminal to the system would erase the last character from the end of the editing buffer, and would be normally displayed as an '<tt>{{mono|#</tt>}}' symbol, which users would have to recognize as denoting a "rubout" of the preceding character (teletypewriters not being physically capable of erasing characters oneonce they have been printed on the paper).{{sfn|Bourne|1983|p=8}}{{sfn|Bourne|1983|p=130&ndash;131}}{{sfn|Bourne|1983|p=287}}{{sfn|Christian|1988|p=26}}{{sfn|Leffler|McKusick|Karels|Quarterman|1989|p=262}}

cbreak mode is one of two character-at-a-time modes. ([[Stephen R. Bourne]] jokingly referred to it {{harv|Bourne|1983|p=288}} as a "half-cooked" and therefore "rare" mode.) The line discipline performs no line editing, and the control sequences for line editing functions are treated as normal character input. Applications programs reading from the terminal receive characters immediately, as soon as they are available in the [[input queue]] to be read. However, the "interrupt" and "quit" control characters, as well as modem flow control characters, are still handled specially and stripped from the input stream.{{sfn|Bourne|1983|p=288}}{{sfn|Leffler|McKusick|Karels|Quarterman|1989|p=260}}

With the BSD UnicesUnixes came [[Job control (Unix)|job control]], and a ''new terminal driver'' with extended capabilities.{{sfn|Leffler|McKusick|Karels|Quarterman|1989|p=262}} These extensions comprised additional (again programmatically modifiable) special characters:

* The "word erase", "literal next", and "reprint" characters (by default {{keypress|Control|W}}, {{keypress|Control|V}}, and {{keypress|Control|R}} &mdash; ASCII [[End Transmission Block character|<code>ETB</code>]], [[Synchronous idle|<code>SYN</code>]], and [[C0_and_C1_control_codesC0 and C1 control codes#C0_.28ASCII_and_derivatives.29ASCII|<code>DC2</code>]]) performed additional line editing functions. "word erase" erased the last word at the end of the line editing buffer. "literal next" allowed any special character to be entered into the line editing buffer (a function available, somewhat inconveniently, in Seventh Edition Unix via the backslash character). "reprint" caused the line discipline to reprint the current contents of the line editing buffer on a new line (useful for when another, background, process had generated output that had intermingled with line editing).{{sfn|Leffler|McKusick|Karels|Quarterman|1989|p=260}}

[[System III]] introduced a new programming interface that combined Seventh Edition's separate <code>ioctl()</code> operations to get and set flags and to get and set control characters into calls that used a <code>termio</code> structure to hold both flags and control characters and that could get them in a single operation and set them in another single operation. It also split some of the flags from the Seventh Edition interface into multiple separate flags, and added some additional capabilities, although it did not support job control or the cooked-mode enhancements of 4BSD.<ref>{{cite web|title=System III tty(4) man page source|url=http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/man4/tty.4|accessdateaccess-date=October 5, 2012}}</ref> For example, it replaced the "cooked", "cbreak", and "raw" modes of Seventh Edition with different abstractions. The recognition of signal-generating characters is independent of input mode, and there are only the two input modes: canonical and non-canonical. (This allows a terminal input mode not present in Seventh Edition and BSD: canonical mode with signal generation disabled.)

One of the major problems that the POSIX standard addressed with its definition of a general terminal interface was the plethora of programmatic interfaces. Although by the time of the standard the behaviour of terminals was fairly uniform from system to system, most UnicesUnixes having adopted the notions of line disciplines and the BSD job control capabilities, the programmatic interface to terminals via the <code>ioctl()</code> system call was a mess. Different UnicesUnixes supplied different <code>ioctl()</code> operations, with different (symbolic) names, and different flags. Portable source code had to contain a significant amount of conditional compilation to accommodate the differences across software platforms, even though they were all notionally Unix.{{sfn|Zlotnick|1991|p=157}}

POSIX also introduced support for job control, with the <code>termios</code> structure containing suspend and delayed-suspend characters in addition to the control characters supported by System III and System V. It did not add any of the cooked-mode extensions from BSD, although [[SunOS]] 4.x, [[System V Release 4]], [[Solaris (operating system)|Solaris]], [[HP-UX]], [[AIX]], newer BSDs, [[macOS]], and [[Linux]] have implemented them as extensions to <code>termios</code>.

{{further2further|[[controllingControlling terminal]]|[[processProcess group]]}}

The data structure used by all of the terminal library calls is the <code>termios</code> structure,{{sfn|Zlotnick|1991|p=162}} whose C and C++ programming language definition is as follows:{{sfn|Zlotnick|1991|p=163}}<sourcesyntaxhighlight lang=cpp enclose=divc>struct termios {

} ;</sourcesyntaxhighlight>

The data type aliases <code>tcflag_t</code> and <code>cc_t</code>, as well as the symbolic constant <code>NCCS</code> and a whole load of symbolic constants for the various mode flags, control character names, and baud rates, are all defined in a standard header <code>termios.h</code>. (This is not to be confused with the similarly named header <code>termio.h</code> from System III and System V, which defines a similar <code>termio</code> structure and a lot of similarly named symbolic constants. This interface is specific to System III and System V, and code that uses it will not necessarily be portable to other systems.){{sfn|Zlotnick|1991|p=162&ndash;163}}

The structure's fields are (in summary, for details see the main article{{clarify|date=August 2018}}):

The library functions are (in summary, for details see the main article{{clarify|date=August 2018}}):

{{refbegin|1}}

first=Stephen R.|last=Bourne|authorlinkauthor-link=Stephen R. Bourne|

first=Kaare|
last=Christian|

publisher=John Wiley &amp; Sons|

isbn=978-0-471-84781-6|

first=Stephen|
last=Coffin|

isbn=978-0-07-881653-6|

first=AEleenÆleen|last=Frisch|

first1=Samuel J.|
last1=Leffler|

first2=Marshall Kirk|
last2=McKusick|authorlink2
author-link2=Marshall Kirk McKusick|

first3=Michael J.|
last3=Karels|

first4=John S.|
last4=Quarterman|authorlink4
author-link4=John Quarterman|

isbn=978-0-201-06196-3|

first=Fred|
last=Zlotnick|

isbn=978-0-8053-9605-8|

workjournal=The Open Group Base Specifications|version=6|

first=Donald A.|
last=Lewine|

isbn=978-0-937175-73-6|