Originally, "tty" had two definitions: the hardware (now the emulator) and the driver (interfaced through /dev/pty* or /dev/tty*).
The hardware/emulator was/is responsible for:
- Taking a stream of data and presenting it; this included interpreting control sequences like "move cursor left", "blinking cursor", "clear-screen" although these control sequences were often different among manufacturers.
- Sending keycodes for keys typed by the user; most of these were standard ASCII characters, but some terminals sent propriety keycodes for even standard keys.
The 'tty' driver was responsible for:
- Managing the buffering, in raw or canonical mode; for example, buffering a line of characters until Enter is pressed.
- Managing the control flow; e.g. being able to stop/continue with Cntl-s/Cntl-q.
- Translating propriety keycodes to standard ASCII, where applicable.
- Intercepting certain control characters (like Cntl-c and Backspace) and processing them appropriately (send SIGINT on a Cntl-c or signal an EOF on Cntl-d.
- Canonical display of characters, for example, if
echo
is turned off, then do not send feedback (character typed) back to the terminal.
The terminfo and termcap databases managed what terminal control characters should be sent for an operation (like 'clear-screen'). These control sequences were/are not interpreted by the driver, but by the hardware/emulator.
I found this paragraph in a withdrawal letter for FIPS which might be why it was withdrawn:
excerpt from withdrawal letter
It is no longer necessary for the government to mandate standards
that duplicate industry standards. Federal government departments and
agencies are directed by the National Technology Transfer and
Advancement Act of 1995 (P.L. 104-113), to use technical industry
standards that are developed in voluntary consensus standards bodies.
There is also this letter/email:
From: "richard l. hogan"
<Richard=L.=Hogan%dpi%hqnmd@mcmcban6.er.usgs.gov> Date: Tue, 29 Oct
96 9:20:26 CST Subject: Withdrawal of FIPS
Which discusses that the NIST and the Dept. of Commerce were dropping national designations for things such as ANSI 3.64 when they already had a international designation (ISO).
excerpt from that letter/email
One of the pieces of legislation that, according to NIST and the
Department of Commerce, enabled the FIPS program was rescinded this
year. The law - sometimes referred to as the Brooks Act - contained
specific requirements for establishing uniform standards for
information processing in the Federal government and for making those
standards mandatory in Federal procurement actions. OMB Circular A-119
further clarified that mandatory Federal standards took precedence
over voluntary national and international standards. Now, as a result
of treaty negotiations making the Untied States part of the World
Trade Organization, the Books Act has been replaced with new
legislation that requires Federal agencies to consider voluntary
international and national standards FIRST in procurement actions and
to cite Federal standards only when no appropriate international or
national standards exist.
In many cases FIPS have international (ISO) or national (ANSI)
standard equivalents. For example, FIPS 123 (Data Descriptive Format
for Information Interchange) is also ISO-8211. The change in
legislation requires Federal procurements to now cite ISO-8211.
Previously, we were required to cite FIPS- 123. As a result of this
change, NIST has recognized an opportunity to make government "work
better and cost less" by withdrawing any FIPS that already has an
equivalent ANSI or ISO specification or any FIPS that is not
mandatory; i.e., is just a guideline. What remains on the "active"
FIPS list are mandatory Federal standards which currently have no ANSI
or ISO equivalent; for example, the Spatial Data Transfer Standard
(FIPS 173-1) and the Government Information Locator Service (FIPS
192).
NIST is not withdrawing important standards like Pascal, FIPS 109;
SGML, FIPS 152; or Hydrologic Unit Codes, FIPS 103. The proper way to
look at this action is that NIST is withdrawing the Federal
designation of these standards in favor or their national or
international standards designations; ANSI X3.97-1993 for FIPS 103,
ISO 8879 for FIPS 152, and ANSI X3.145-1986 for FIPS 103. From a user
point of view, this action by NIST is nothing more than a way to
assure the designation change required by the new legislation.
I would interpret this as follows: Since ECMA-48 already covered the standard at an international level there was no need to create redundant standards within ANSI.
Best Answer
Console programs typically use curses or one of its successors¹ to build the sorts of text user interfaces you're talking about.
These libraries use one of two databases, called
termcap
andterminfo
.² These databases contain maps that tell the library what codes to send to get desired actions with a large number of diverse terminal types. The vast majority of the terminal types you'll find defined in these databases didn't survive the days of real terminals, and so are now only of historical interest.ANSI Terminals
Modern Unix terminal emulators³ use the ANSI X3.64 protocol or one of its later variants:
ANSI X3.64: A standard for controlling "glass terminals" — as opposed to teletypes — it is based on special sequences of characters which the remote terminal interprets. For instance, if the Unix box wants to tell an ANSI X3.64 compatible terminal to move its cursor to the upper left corner of the screen, it sends the characters
ESC
[
1
;
1
H
. The first two characters tell the terminal to expect a control sequence, the 1s are the row and column, andH
is the command meaning "move cursor".⁴Trivia: many PC BBSes used ANSI codes, too. (Still do, actually.)
DEC VT100: The first really popular ANSI-compatible glass terminal was Digital Equipment Corporation's VT100. By proving ANSI's de jure standard out in the marketplace, it established a de facto standard that is still important today.
Sometimes you see this called the VT102 protocol, that being a later cost-reduced — and therefore more popular — version of the VT100 plus all available expansion options built-in.
The DEC terminal protocols are a backwards-compatible series, extending from the first ANSI-compatible model introduced in 1978 (the VT100) up through the VT500 series models produced by Boundless Technologies after they bought the terminal business from DEC in 1995. (Boundless is now out of business, but their terminals still pop up on the used market from time to time.)
xterm: A kind of amalgam of ANSI and the VT-whatever standards. Whenever you're using a GUI terminal emulator like
xterm
or one of its derivatives, you're usually also using thexterm
terminal protocol, typically the more modernxterm-color
orxterm-color256
variants.Linux: The Linux console also uses an extended variant of the ANSI terminal protocol, in the same spirit as the
xterm
protocols. Most of its extensions have to do with the differences between a PC and a glass terminal. For example, the IBM keyboard has some keys not on a DEC VT-whatever. (And vice versa.)Some Unix systems have their own console terminal protocol, too. There's the
scoansi
ANSI X3.64 variant for SCO Unixes, for example.A typical terminal emulator program is something of a mongrel, and doesn't emulate any single terminal model exactly. It might support 96% of all DEC VT escape sequences up through the VT320, yet also support extensions like ANSI color (a VT525 feature) and an arbitrary number of rows and columns. The 4% of codes it doesn't understand may not be missed if your programs don't need those features, even though you've told
curses
(or whatever) that you want programs using it to use the VT320 protocol. Such a program might advertise itself as VT320 compatible, then, even though, strictly speaking, it is not.⁵Non-ANSI Terminals
There are a few other notable standards that you still sometimes come across:
Wyse: One of the earliest independent producers of glass terminals, Wyse started making terminals in the early 1980s before workstation computing began displacing minicomputers. Although Wyse terminals were able to emulate the VT100 and other popular terminal protocols, they also had their own native codes.
IBM 3270: Although this is not strictly a "Unix" terminal type, the need to connect Unix systems to IBM mainframes led to the creation of IBM 3270 series terminal emulator programs, which you can still find in use. Emulators for the later IBM 5250 series terminals are also fairly common, most often used these days for connecting to AS/400 and System i minicomputers.
Tektronix 4014: Before PCs and workstations largely displaced glass terminals and thus made bitmapped graphics a standard feature, there were expensive graphics terminals which drew graphics on the screen in response to text commands similar to the escape sequences described above. Probably the most popular of these was the Tektronix 4010 series.
They were quite fun to use. You could write a program that drew a graphic, but then instead of simply running it to draw on your local terminal, you could redirect its output to a file:
You could then send that file to someone else, and they could
cat
it on their Tek terminal to see the graphic without having your program. Part of the charm was how slow these terminals were in drawing, so you could watch the graphic build up over several seconds.Working With Unix Terminal Emulation Today
You can find out which terminal standard you're asking libraries like
curses
to use by looking at theTERM
environment variable:When you
ssh
to another system, theTERM
variable is carried along so the remote Unix box knows how to communicate with your local terminal.Because so many of these protocols are ANSI X3.64 variants, and because the ubiquitous ASCII and UTF-8 character coding standards take care of so much else, an incorrect
TERM
variable isn't typically catastrophic. Things that tend to break are extended keys like Home and Page Up, Alt-whatever key combinations, and typographical display features like color, boldface, etc.Footnotes:
Most commonly, ncurses.
There are also outright competitors to the
curses
API, such as S-Lang.AT&T promulgated
terminfo
as a replacement for BSD'stermcap
database, and it was largely successful in replacing it, but there are still programs out there that still use the oldtermcap
database. It is one of the many BSD vs. AT&T differences you can still find on modern systems.My macOS box doesn't have
/etc/termcap
, but it does have/usr/share/terminfo
, whereas a standard installation of FreeBSD is the opposite way around, even though these two OSes are often quite similar at the command line level.minicom
,xterm
,mintty
, GNOME Terminal, Terminal.app, etc.Properly-written Unix programs don't emit these escape sequences directly. Instead, they use one of the libraries mentioned above, telling it to "move the cursor to position (1,1)" or whatever, and the library emits the necessary terminal control codes based on your
TERM
environment variable setting. This allows the program to work properly no matter what terminal type you run it on.Old text terminals had a lot of strange features that didn't get a lot of use by programs, so many popular terminal emulator programs simply don't implement these features. Common omissions are support for sixel graphics and double-width/double-height text modes.
The maintainer of
xterm
wrote a program calledvttest
for testing VT terminal emulators such asxterm
. You can run it against other terminal emulators to find out which features they do not support.