The POSIX terminal interface is the generalized abstraction, comprising both an application programming interface for programs, and a set of behavioural expectations for users of a 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.
General underlying concepts
Hardware A multiplicity of I/O devices are regarded as "terminals" in Unix systems. These include: serial devices connected by a serial port such as printers/teleprinters, teletypewriters, modems supporting remote terminals via dial-up access, and directly connected local terminals display adapter and keyboard hardware directly incorporated into the system unit, taken together to form a local "console", which may be presented to users and to programs as a single CRT terminal or as multiple virtual terminals software terminal emulators, such as the xterm, Konsole, GNOME Terminal, and Terminal programs, and network servers such as the rlogin daemon and the SSH daemon, which make use of pseudoterminals
Terminal intelligence and capabilities Intelligence: terminals are dumb, not intelligent Unlike its mainframe contemporaries, but like other minicomputer operating systems, the original Unix system was developed solely for dumb terminals, and that remains the case today. A terminal is a character-oriented device, comprising streams of characters received from and sent to the device. Although the streams of characters are structured, incorporating control characters, escape codes, and special characters, the I/O protocol is not structured as would be the I/O protocol of smart, or intelligent, terminals. There are no field format specifications. There's no block transmission of entire screens (input forms) of input data.
By contrast mainframes commonly use block-oriented terminals.
Capabilities: terminfo, termcap, curses, et al.
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 keystrokes (home key, end key, help key, PgUp key, PgDn key, insert key, delete key, and so forth).
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 and ncurses libraries. Application programs use the terminal capabilities to provide textual user interfaces with windows, dialogue boxes, buttons, labels, input fields, menus, and so forth.
Controlling environment variables: TERM et al. 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 TERM environment variable (and, optionally for the termcap and terminfo libraries, the TERMCAP and TERMINFO environment variables, respectively). 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 getty program (or equivalent) sets the TERM environment variable according to a system database (variously inittab or the configuration files for the ttymon or launchd programs) defining what local terminals are attached to what serial ports and what terminal types are provided by local virtual terminals or the local system console. A dial-up user on a remote terminal is not using the type of terminal that the system commonly expects on that dial-up line, and so manually sets the TERM environment variable immediately after login to the correct type. (More usually, the terminal type set by the getty program for the dial-up line, that the system administrator has determined to be used most often by dial-up users with remote terminals, matches the one used by the dial-up user and that user has no need to override the terminal type.) The SSH server daemon (or equivalent such as the rlogin daemon) sets the TERM environment variable to the same terminal type as the SSH client. The software terminal emulator, using a pseudoterminal, sets the TERM 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 xterm as the terminal type, for example. The GNU Screen program sets screen as the terminal type.
Job control
Terminals provide job control facilities. Interactively, the user at the terminal can send control characters that suspend the currently running job, reverting to the interactive job control shell that spawned the job, and can run commands that place jobs in the "background" or that switch another, background, job into the foreground (unsuspending it if necessary).
Line disciplines
Strictly speaking, in Unixes 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.
In Seventh Edition Unix, BSD systems and derivatives including macOS, and Linux, each terminal device can be switched amongst multiple line disciplines. In the AT&T STREAMS system, line disciplines are STREAMS modules that may be pushed onto and popped off a STREAMS I/O stack.
History The POSIX terminal interface is derived from the terminal interfaces of various Unix systems.
Early Unixes: 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 key was pressed on the terminal to end line editing. The 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 '' symbol followed by a newline sequence to move the print position to a fresh blank line. The 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 '' symbol, which users would have to recognize as denoting a "rubout" of the preceding character (teletypewriters not being physically capable of erasing characters once they have been printed on the paper).
From a programming point of view, a terminal device had transmit and receive baud rates, "erase" and "kill" characters (that performed line editing, as explained), "interrupt" and "quit" characters (generating signals to all of the processes for which the terminal was a controlling terminal), "start" and "stop" characters (used for modem flow control), an "end of file" character (acting like a carriage return except discarded from the buffer by the read() system call and therefore potentially causing a zero-length result to be returned) and various basic mode flags determining whether local echo was emulated by the kernel's terminal driver, whether modem flow control was enabled, the lengths of various output delays, mapping for the carriage return character, and the three input modes.
The three input modes were: line mode (also called "cooked" mode)
In line mode the line discipline performs all line editing functions and recognizes the "interrupt" and "quit" control characters and transforms them into signals sent to processes. Applications programs reading from the terminal receive entire lines, after line editing has been completed by the user pressing return. cbreak mode
cbreak mode is one of two character-at-a-time modes. (Stephen R. Bourne jokingly referred to it 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. raw moderaw mode is the other of the two character-at-a-time modes. The line discipline performs no line editing, and the control sequences for both line editing functions and the various special characters ("interrupt", "quit", and flow control) are treated as normal character input. Applications programs reading from the terminal receive characters immediately, and receive the entire character stream unaltered, just as it came from the terminal device itself.
The programmatic interface for querying and modifying all of these modes and control characters was the ioctl() system call. (This replaced the stty() and gtty() system calls of Sixth Edition Unix.) Although the "erase" and "kill" characters were modifiable from their defaults of and , for many years they were the pre-set defaults in the terminal device drivers, and on many Unix systems, which only altered terminal device settings as part of the login process, in system login scripts that ran after the user had entered username and password, any mistakes at the login and password prompts had to be corrected using the historical editing key characters inherited from teletypewriter terminals.
BSD: the advent of job control
With the BSD Unixes came job control, and a new terminal driver with extended capabilities. These extensions comprised additional (again programmatically modifiable) special characters: The "suspend" and "delayed suspend" characters (by default and — ASCII SUB and EM) caused the generation of a new SIGTSTP signal to processes in the terminal's controlling process group.