For a quick attempt to install a terminal see Quick Install.
Copyright 1998-2007 by David S. Lawyer. mailto:dave@lafn.org
Please freely copy and distribute (sell or give away) this document in any format. Send any corrections and comments to the document maintainer. You may create a derivative work and distribute it provided that you:
If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.
While I haven't intentionally tried to mislead you, there are likely a number of errors in this document. Please let me know about them. Since this is free documentation, it should be obvious that I cannot be held legally responsible for any errors.
Any brand names (starts with a capital letter such as MS Windows) should be assumed to be a trademark). Such trademarks belong to their respective owners.
Greg Hankin's Serial-HOWTO v.1.11 (1997) section "How Do I Set Up A Terminal Connected To My PC?" was incorporated into v1.00 at various places (with Greg's permission). v1.09 has about 25 changes (and error corrections) suggested by Alessandro Rubini who reviewed this terminal as a console for a monitorless PC (using ttysnoop). (v1.26) I fixed about 25 typos, etc. found by Alain Cochard. Jeremy Spykerman told me about using a keyboardless terminal as a console for a monitorless PC (using ttysnoop). Numerous other people have made a suggestion or two or found a few typos. Thanks.
Please let me know of any errors in facts, opinions, logic, spelling, grammar, clarity, links, etc. But first, if the date is over a few months old, check to see that you have the latest version. Please send me any info that you think belongs in this document.
In order to fully utilize all the features of a certain real terminal, one needs the terminal manuals that came with the terminal when it was new. If you don't have a manual, this HOWTO may be of some help. One way to solve this problem would be for terminal manufacturers put their manuals on the Internet.
New versions of the Text-Terminal-HOWTO should be released every year or so. To get the latest version go to an LDP mirror sites (see: http://www.tldp.org/mirrors.html). To quickly check the date of the latest version look at Text-Terminal-HOWTO.html. The version your are currently reading is: v1.41 February 2008 .
For a full revision history going back to the first version in 1998 see the source file (in linuxdoc format): (cvs) Text-Terminal-HOWTO.sgml
Go to the nearest mirror site (per above) to get HOWTOs.
Configuration means the same as set-up. While Linux commands take options (using - or -- symbols), options in a broader sense include various other types of choices. Install in the broad sense includes setting up (configuring) software and hardware. A statement that I suspect is true (but may not be) ends with 2 question marks: ?? If you know for sure, let me know.
A terminal consists of a screen and keyboard that one uses to communicate remotely with a (host) computer. One uses it almost like it was a personal computer but the terminal is remote from its host computer (on the other side of the room or even on the other side of the world). Programs execute on the host computer but the results display on the terminal screen. The terminal's computational ability is relatively low compared to the host computer but often the terminal is just a personal computer (PC) itself which has been programmed to behave like a terminal. It often doesn't allow the user full access to either the pc it runs on nor the host it is connected to. you formerly found this type of terminal at libraries and schools. But some terminals permitted the user to log into the host computer and provide access dependent on the user's status.
A text-terminal is a terminal which only displays text on the screen without pictures. Today, it's mostly done by PCs which emulate the terminals of olden days.
In the olden days of mainframes, from the mid 1970's to the mid 1980's, most people used real text-terminals to communicate with large computers. These real text-terminals were neither computers nor emulated text-terminals. They consisted only of a screen, keyboard, and only enough memory to store a screenfull or so of text (a few kilobytes). Users typed in programs, ran programs, wrote documents, issued printing commands, etc. A cable connected the terminal to the computer (often indirectly). It was called a terminal since it was located at the terminal end of this cable. Some text-terminals were called "graphic" but the resolution was poor and the speed slow by today's standards due to the high cost of memory and the limited speed of the conventional serial port, etc.
Today, real terminals are becoming rarities and most people that use terminals use a personal computer to emulate a terminal. Almost everyone who uses Linux uses terminal emulation. When you are not using an X Window GUI at a Linux PC, you are likely using a text interface (virtual terminal). It's also called a command line interface. In X Window one can also get a command line interface using one or more terminal windows by using an x-terminal-emulator with names such as xterm, gnome-terminal, or konsole (KDE). All these use software to emulate a real terminal.
A real text-terminal is different from a monitor or x-terminal-emulator because the simple character images that get displayed on the text-terminal are stored right inside the terminal in it's memory. For a monitor or x-terminal-emulator, the images are stored in the video card of the PC and/or in the PC's memory itself. The text-terminal's keyboard plugs into the the terminal and is part of the terminal while a PC's keyboard plugs into the computer.
For a monitor, the video images are sent by a short cable running from the video card to the monitor while for a text-terminal there is a bi-directional flow of character bytes in a long cable between the computer's serial port and the PC it's connected to. Most text terminals do not have mice.
In network client-server terminology, one might think that a real terminal is the client and that the host computer is the server. The terminal has been called a "thin client" by some. But it is not actually a "client" nor is the host a "server". The only "service" the host provides is to receive every letter typed at the keyboard and react to this just like a computer would if you typed at its keyboard. The terminal is like a window into the computer just like a monitor (and keyboard) are. You may have already used virtual terminals in Linux (by pressing Left Alt-F2, etc.). A real terminal is just like running such a virtual terminal but you run it on its own terminal screen instead of having to share the monitor screen. In contrast to using a virtual terminal at the console (monitor), this allows another person to sit at a terminal and use the same computer simultaneously with others. Such user interfaces are not "clients".
There are various conflicting definitions of "dumb terminal" but as time goes by, more and more terminals are called dumb. This document mainly covers text terminals which display only text on the screen. It could have been titled "Dumb-Terminal-HOWTO". But in some magazines articles, any terminal, no matter how smart, including ones which present a full graphical user interface (GUI), are called dumb. If all terminals are "dumb" then there is no point of prefixing the word "dumb" to terminal (except as a sales pitch to sell computers or the like instead of terminals). Due to the ambiguous meaning of "dumb terminal" it is not classified here as a type of terminal.
For a text terminal, a 2-way flow of information between the computer and the terminal takes place over the cable that connects them together. This flow is in bytes (such as ASCII) where each byte usually represents a printable character. Bytes typed at the keyboard go to the computer and most bytes from the computer are displayed on the terminal screen. Special control bytes (or sequences of bytes) from the computer tell the terminal where to move the cursor to, what to erase, where to begin and end underlining and/or blinking and/or bold, etc. There are often hundreds of such special commands and most terminals can even change fonts.
The communication uses characters (letters) encoded using a code chart for the character set being used. Usually, the first 128 bytes out of 256 possible bytes use ASCII codes. Terminals for Unix-like systems, normally connect to computers via a cable running between the asynchronous serial ports (RS-232-C = EIA-232-D) of the host computer and the terminal. Sometimes the connection is via modem or terminal server, etc.
Other names for "text terminal" are "general purpose terminal", "general display terminal", "serial monitor", "serial console" (if it's used like a console), "serial terminal", "dumb terminal", "character-cell terminal", "character terminal", "ASCII/ANSI terminal", "asynchronous terminal", "data terminal", "video terminal", "video display terminal" (VDT), and "green terminal" (since many used green displays). These names (especially "dumb terminal") are sometimes used to mean emulating a text terminal on a PC with a command line interface such as Linux. In olden days "video display unit" (VDU) meant text terminal but strictly speaking, it excludes the keyboard.
"Block mode" was used exclusively by old IBM mainframe terminals but many modern terminals also have this capability (which is not used much). In block mode, the characters you type are temporarily retained in the terminal memory (and may possibly be edited by a built-in editor at the terminal). Then when the send key (or the like) is pressed, a block of characters (sometimes just a line of characters) is sent to the computer all at once. Block mode (as of late 1998) is not supported by Linux. See section Block Mode.
Many text terminals can display bit-mapped images, but not in color. Unfortunately, the popular image formats used on the Internet are not supported. The protocols for terminal graphics include: Tektronix Vector Graphics, ReGIS (DEC), Sixel (DEC), and NAPLPS (North American Presentation Level Protocol Syntax).
Even without bit-mapped images, ordinary text terminals can sort of display images. One may form arrows <--- and draw boxes with |__|, etc. With special graphic character sets that have a lot of special characters for line drawing, much more is possible. But even without a graphic character set, one may produce "ascii graphics" art. The term "graphics terminal" usually means a terminal that can display bit mapped images. However, this term is sometimes applied also to text-only terminals since text is a limited form of graphics.
There are two basic types of graphics displays: raster and vector (rarely used). Raster graphics (bit-mapped) puts dots on the screen by horizontal scan lines drawn by an electron beam (or by activating pixels or dots on a flat screen). Vector graphic displays were intended to be used for monochrome screens that don't have any dots. They use smart electronics to draw lines and curves with an electron beam that can continuously move in any direction (just like a pen or pencil). True vector graphics draws high quality lines without noticeable zig-zags but is both rare and expensive. For more details see http://www.cca.org/vector/. Raster graphics is almost universally used today for both PCs and text terminals. For PCs, images encoded in vector graphic format can't be drawn as continuous lines due to the electronic limitations but they can be translated to raster graphics format for display (with a resulting drop in image quality).
Since "thin clients" are not text terminals, this HOWTO only provides a brief overview of them. There are other HOWTOs that cover them in more detail. See Related HOWTOs, etc.. Thin clients are thin (minimal) client computers that behave something like terminals. Since text terminals (except for very old ones) run an embedded operating system, they are also like a computer. Thin-clients need more computing power. In contrast to text-terminals thin clients all display a modern high-speed GUI. They are dependent on more powerful computers (servers) for their operation. For a true thin client terminal, the computing work and disk storage will all be done on the server. At the other extreme, most of this work and storage is done at the thin client but some things such as administration, still depend on the server. Since such a client is not really "thin" it may more correctly be called a "fat client".
Such clients may be created from an ordinary PC by using software or may be a stand-alone piece of hardware. But the stand-alone hardware will often use a conventional PC monitor plus a small box for the computer part of the hardware. Linux seems to favor the use of PCs as a client.
Some claim that text-terminals are also thin clients but they are not really since they don't conform to the client-server model. However, connecting a terminal via telnet does invoke the client-server model in the use of telnet as a means of transport of data. But the relation of the text-terminal to it's host is not one of client-server. The text-terminal is just another means of access to the computer just like the monitor and its keyboard is. One could apply this same reasoning to a thin client and say that the client-server relationship is only for the transport of data.
Thus a thin client is like a terminal. It has a GUI with a mouse that makes it seem like you are using a computer. You are, but that computer may be far away and have many other people using it at the same time you are. Communication is over a high speed network cable or even over the Internet. Some thin clients can, in addition, emulate a text terminal and have a serial port connector for that purpose. One even has a USB interface.
There are various types of thin clients. One type is the "Window Terminal" which runs under MS servers (and software). Another type is the "network computer" which is supposed to be platform neutral. This implies they should work with both MS Windows and Linux but early models may not be easy to use with Linux. For Linux, the X Window protocol is used. See Thin clients and NCs under Linux
These are true terminals since all the computing work is done by a server running Windows. They are also called "Window-based Terminals" (WBT). These terminals (clients) are something like computers since they often run an embedded operating system such as Linux or Microsoft's CE, NT, or XP. It's often stored in flash memory so that it may be updated. Also, ordinary PCs can be used as clients (including, in some cases, Linux PCs) with the appropriate software, Some clients can support X Window (from a Linux server) and some can emulate text-terminals. Many so called "network computers" can also run X Window. This will be discussed in the next section.
The server for these clients usually runs MS's Terminal Services (for Windows 2000 servers). Prior to this there was Windows NT Terminal Server Edition (starting mid 1998 with codename "Hydra"). MS uses RDP (Remote Desktop Protocol) which is based on the ITU T.120 protocol. In addition, there is an optional ICA protocol (with added features) which can inter-operate with RDP.
Prior to this there was a modified Windows NT 3.51 (1995) called "WinFrame" by Citrix using the proprietary ICA protocol (Independent Computing Architecture). After MS came out with its own terminal server, Citrix still remained on the scene. It created MetaFrame software (formerly pICAsso) as an add-on to MS's Terminal Server (or Services) so that it could support ICA-based terminals and provide other additional features. Before MS got into the act, there were other proprietary systems for terminals that could display the MS Windows GUI but later on they all switched to support Microsoft's system.
PCs running Linux can be turned into ICA based client terminals using "free" (in price only) proprietary ICA client software from Citrix: Installing the Linux Client. Unfortunately, MS requires that you purchase a license to cover the clients, even if the clients all run Linux. So if you want to save money on software costs by using Linux, you'll have to go all-Linux and use both Linux servers and clients using the free X-Window protocol.
The above is sometimes called "network computing" since the terminals and servers connect to each other over a network (such as the common TCP/IP based network used by both Linux and MS). Network computers may be somewhat different as described below.
These are neither true computers nor true terminals but are something in-between. One type of network computer (NC's) is a computer with a CPU but no hard Disk. The OS it needs to run is sent to it over a network. NCs are full-graphics and use the services of a server computer. They are a little different from terminals since some (or most) of the programs they run may execute on their own CPU chip. Running a browser was supposed to be one of their primary functions and thus Java code applets may be sent to them for execution. Many NCs support X Window so that one may use a Linux server to support it. Such a server may be called a "Linux Terminal Server". IBM called their NC a "NetStation" but now calls it "NetVista". They should work on Intranet type networks and NetVista can run the Linux OS.
Wintel came out with a "NetPC" which, unlike the above, is almost a PC computer. However, it has no removable disks so users can't install their own software or obtain copies of anything.
There is a "Linux Terminal Server Project" (LTSP or ltsp) to use Linux as a server for diskless thin clients. They use X Window and by default, applications run on the server. But with additional effort, one can set it up so that some or all applications run on the "terminal". See http://www.ltsp.org/.
"Terminal" in LTSP is actually a thin (or fat) client. This project's client can also run a telnet session and thus behave like a text-terminal. A software package named "lts" for the LTSP is available in the major Linux distributions.
It's claimed that if one has only a few "terminals", they will work without the ltsp software. But if one has many "terminals", ltsp software is needed. So use ltsp if what you want to do is to use old PCs, etc. as diskless thin clients. It works OK on systems with over 100 thin-client workstations.
Linux provides NFS (Network File System) so that if ordinary computers are connected to each other via a network, then a person on one computer can run programs on another computer. Such a program sends messages over the network so that it appears just like a program was being run by your local computer. But such a program is actually being run on another computer on the network. It works also with X Window so that one may see GUI images generated on another computer.
Linux also allows a computer to be diskless and boot over a network. See the "Terminal Server Project" above which has special software for this purpose. Network-boot-HOWTO gives an overview. Older documents are Diskless-HOWTO and Diskless-root-NFS-HOWTO. Thus using a diskless computer which runs NFS enables you to run programs on another computer (the server). This is just like using a NC (Network Computer). It's not really a NC but it's emulating a type of NC. It's also often called a "terminal" and in some sense it is.
Thus if you have an old PC with an ethernet card (NIC) you may be able to use it as a NC. One source of info on this is Thinclient-HOWTO. Even if your old PC doesn't have a NIC, you could still use it to emulate a text-terminal. See Terminal Emulation.
There are also a number of genuine Network Computers (NC) that will work with a Linux server. Today some NCs run the Linux OS inside the NC. Before Linux became popular, NCs didn't run the Linux OS but required some other OS. But even if the NC uses a non-linux OS, it's often possible to make it work with a Linux Server. The non-linux OS is simply stored as files on the Linux Server. Then when the NC starts up it sends a message to the Linux Server asking for the non-linux OS files. This non-linux OS is thus sent to the NC over the network and the NC boots.
The Linux Server runs the NFS and X Window both of which must be supported by the NC. This enables one to use the NC as if it were an X Window terminal.
There are some Linux HOWTOs for certain brands of NCs:
There are 3 different types of hardware arrangements for thin clients. The first type just uses a PC computer as a thin client by emulating a thin client. It really isn't a thin client but it behaves like one. The second type looks just like a text-terminal. It just looks like a monitor, with a connector for a keyboard and another connector for a network cable. It's a dedicated thin client and can't be used for anything else. The third type looks like a tiny computer. It uses a standard PC monitor and keyboard both of which plug into a small box which is a "thin" computer. This box provides an interface between the monitor/keyboard and the network.
Promoters of NCs and related Window-Terminals projected that they would soon replace millions of PCs. In 1998 about .7 million thin clients were sold worldwide with (about 27% of them being NCs). In 1999 it dropped to .6 million but went up to .9 million in 2000 (vs. 1.3 million predicted). In 2001 it reached 1.09 million with 1.4 million predicted for 2002.
Microsoft servers (as of 2003) still dominate the market, but the clients may run Linux for which users still have to pay license fee for each Linux client to Microsoft. Thus free all-linux systems are gaining ground.
A major reason why growth was not as rapid as predicted is that PCs have come down in price in recent years so that they are often not much more expensive than a thin client. However, it's argued that even though thin clients may cost the same as PCs, the maintenance and administration costs are less. Note that thin clients sometimes replace text terminals instead of PCs.
Since a PC has a screen and keyboard (as does a terminal) but also has much more computing power, it's easy to use some of this computing power to make the PC computer behave like a text terminal. This is called "terminal emulation". They usually emulate text-terminals. See Terminal Emulation
This is a quick procedure to install a terminal without going through a Setup procedure for both the terminal and the host computer. It probably will not work right if the terminal happens to have been set up incompatible with the computer. If you don't understand some of it you'll need to consult other parts of this document for more info.
To install a terminal, first look in /etc/termcap or
terminfo.src to find an entry for it (see
Terminfo and Termcap (detailed)). Figure out what serial port
you'll connect it to and what the tty designation is for that port
e.g. ttyS1, see
Device Names). As the
root user, edit /etc/inittab and add a getty command next to
the other getty commands. The format of the getty command depends on
which getty program you use. agetty (called just getty in
the Debian distribution) is the easiest (no configuration file). See
the "info" or "man re getty. For getty parameters use
the terminfo (or termcap) name (such as vt100) for your terminal.
Type in a baud-rate that the terminal supports. But if you set the
baud too high you may need to use (See
Flow Control).
Then physically connect the main serial port of the terminal to the chosen serial port of the computer with a file-transfer (null modem) cable and turn on the terminal. Don't expect most ready-made cables to be wired correctly for hardware flow control. Make sure the baud-rate of the terminal is set the same as you gave to getty and that its "data bits" is 8. Then at the computer console type "init q" to apply the changes you made to the inittab file. You should now see a login prompt at the terminal. If you don't, tap the terminal's return key. If this doesn't work read more of this document and/or see Trouble-Shooting.
PC's are so powerful today that just one PC can often support several persons using it at once, especially if they are doing low-load tasks such as text editing, data entry, etc. One way to do this is to connect a number of terminals to a single PC (or other host computer) by modems or direct cable connection. To do this, it's usually best to have a multi-user operating system such as Linux so that each user at a terminal can use the computer independently. This has been called "time sharing" but it's not good terminology today since "distributed" computing over a network is also a type of time sharing. It might be better described as "centralized" computing. But the central computer may be connected to the rest of the world via a network so that terminal users may send email, browse the Internet with the lynx browser, etc. So it's not exactly "centralized" either.
Terminals have seldom been used with PC's because the popular operating systems used for them (Windows, DOS, and Mac) were not multiuser until 1998 (available for MS Windows NT) and previously could not support terminals very well. Now that Linux, a multiuser operating system, is freely available for PC's, the use of terminals with PC's becomes more feasible. The drawback is that text terminals are not smart enough to support the type of graphical user interface (GUI) that many computer users today normally expect.
When Computers (including PCs) were quite expensive, lower hardware costs was a significant advantage of using terminals. Today with cheap PCs, the cost savings is problematical. Here's what I wrote years ago when PCs were more expensive. It's still true today but of less significance.
If several people use the same computer as the same time, there is a reduction in the amount of hardware needed for the same level of service. One type of savings is due to code sharing. The application files on hard disks are shared as well as shared libraries in memory (even when people are running different programs provided they use some of the same functions in their code). Another type of savings is due to reduction of peak load. The hardware of a single PC may be idle most of the time as people slowly type in information, think, talk, or are away from their desks. Having several people on the same computer at once makes good use of much of this idle time which would otherwise be wasted.
These savings are substantial. One may roughly estimate (using statistical theory) that for 9 persons (8 terminals & 1 console) the shared PC only needs only about 3 times as much capacity (in memory, disk storage, CPU power, etc.) as a single PC in order to provide the same level of service per person. Thus the computational hardware for such a shared system should only cost about 1/3 as much per user. However, the cost of the display hardware (CRT's, keyboards, video electronics, etc.) is about the same for both cases. The terminals have the added cost of requiring additional serial ports at the host computer.
For a fair comparison with PC's, the terminals should have the same capabilities as the PC monitors. Unfortunately, color graphic terminals for Linux (X Window) with high speed communication cost about as much as a PC so in this case there not much (if any) savings in hardware costs. But for text terminals there will be some savings, especially if the terminals are obtained used at low cost.
For centralized computing, software (and the updates to software) only need be installed and configured on one host computer instead of several. The person in charge of this computer may control and configure the software which is installed on it. This is advantageous if the person controlling the host computer does an excellent job and knows about the needs and preferences of the other users. Users can be restricted in playing games or surfing the Internet by not installing the software (or by otherwise restricting access to it). Whether or not centralized control is desirable depends on the situation.
With terminals, the computer hardware upgrades take place on only one computer instead of many. This saves installation labor effort. While the cost of the hardware for the host computer upgrade will be more than that for a single PC (since the host needs more computing power than a PC), the cost will be significantly less than upgrading the hardware of a number of PC's being used instead of terminals.
Text terminals are technologically obsolete because for a slightly higher cost of hardware, one could build a smarter terminal (with the same quality of display). This wasn't always the case since around 1980 memory cost thousands of dollars per megabyte. Today with low costs for memory and processors, one could turn a text terminal into a GUI graphic terminal for only about a 10% or 20% increase in hardware cost. Since a PC can emulate a terminal, almost everyone using computers has a terminal emulator available.
The reasons that text terminals are not fully obsolete are:
See also section Some Details on How Terminals Work
Each terminal is connected to a serial port on the host computer (often just a PC). The ports have names/numbers. The first few are: ttyS0, ttyS1, ttyS2, etc.
These are represented by special files found in the /dev (device) directory. ttyS0) corresponds to COM1 in DOS or Windows. ttyS1) is COM2, etc. See Terminal Special Files for details on these and related "devices".
When the host computer starts up it runs the program getty. The getty program runs the "login" program to log people in. See Getty (used in /etc/inittab). A "login:" prompt appears on the screen. People at the terminals log in (after giving their passwords) and then have access to the computer. When it's time to shut the terminal down, one normally logs out and turns the terminal off. See Login Restrictions regarding restricting logins (including allowing the root user to log in at terminal).
If one watches someone typing at a terminal, the letters one types simultaneously appear on the screen. A naive person might think that what one types is being sent directly from the keyboard to the screen with a copy going to the computer (half-duplex like, see next paragraph). What is usually going on is that what is typed at the keyboard is directly sent only to the host computer which in turn echoes back to the terminal each character it receives (called full-duplex). In some cases (such as passwords or terse editor commands) the typed letters are not echoed back.
Full-duplex means that there are two (dual) one-way communication links. Full-duplex is the norm for terminals. Half-duplex is half of a duplex, meaning that there is only a single one-way communication link. This link must be shared by communications going in both directions and only one direction may be used at a time. In this case the computer would not be able to echo the characters you type (and send to it) so the terminal would need to also send each character you type directly to the terminal screen. Some terminals have a half-duplex mode of operation which is seldom used.
The image on a CRT tube will fade away almost instantly unless it is frequently redrawn on the screen by a beam of electrons shot onto the face of the tube. Since text sent to a terminal needs to stay on the screen, the image on the screen must be stored in the memory chips of the terminal and the electron beam must repeatedly scan the screen (say 60 times per second) to maintain the image. See Terminal Memory Details for more details.
The terminal is under the control of the computer. The computer not only sends the terminal text to display on the screen but also sends the terminal commands which are acted on. These are Control Codes (bytes) and escape sequences. For example, the CR (carriage return) control code moves the cursor to the left hand edge of the screen. A certain escape sequence (several bytes where the first byte is the "escape" control code) can move the cursor to the location on the screen specified by parameters placed inside the escape sequence.
The first terminals had only a few such commands but modern terminals have hundreds of them. The appearance of the display may be changed for certain regions: such as bright, dim, underline, blink, and reverse video. A speaker in a terminal can "click" when any key is pressed or beep if a mistake has occurred. Function keys may be programmed for special meanings. Various fonts may exist. The display may be scrolled up or down. Specified parts of the screen may be erased. Various types of flow control may be used to stop the flow of data when bytes are being sent to the terminal faster than the terminal can handle them. There are many more as you will see from looking over an advanced terminal manual or from the Internet links Esc Sequence List
While terminals made for the US all used the same ASCII code for the alphabet (except for IBM terminals which used EBCDIC), they unfortunately did not all use the same escape sequences. This happened even after various ANSI (and ISO) standards were established since these standards were never quite advanced enough. Furthermore, older terminals often lacked the capabilities of newer terminals. This might cause problems. For example, the computer might send a terminal an escape sequence telling it to split the screen up into two windows of specified size, not realizing that the terminal was incapable of doing this.
To overcome these problems a database called "termcap" (meaning "terminal capabilities") was established. Termcap was later superceded by "terminfo". This database resides in certain files on the computer and has a section of it (sometimes a separate file) for each model of terminal. For each model (such as VT100) a list of capabilities is provided including a list of certain escape sequences available. For example blink=\E5m means that to make the cursor start blinking the terminal must be sent: Escape 5 m. See Section Termcap and Terminfo (detailed) for more details. Application programs may utilize this database by calling certain C-Library functions. One large set of such programs (over 200) is named "ncurses" and are listed in the manual page for "ncurses" which comes with a developer's ncurses package. There is also a NCURSES-programming-HOWTO.
The environment variable TERM is the type of terminal Linux thinks you are using. Most application programs use this to look up the capabilities in the terminfo database so TERM needs to be set correctly. But there is more to a correct interface than the computer knowing about the capabilities of the terminal.
For bytes to flow from the computer to the terminal the terminal must be set to receive the bytes at the same baud rate (bits per second) as they are sent out from the terminal. If the terminal is set to receive at 19,200 baud and the computer sends out characters at 9600 baud, only garbage (or perhaps nothing) will be seen on the screen. One selects the baud rate for a terminal (as well as many other features) from the terminals "set-up" menus at the terminal. Most terminals have a large number of options in their "set-up" menus (see Terminal Set-Up (Configure) Details). The computer serial port has options also and these options must be set up in a compatible way (see Computer Set-Up (Configure) Details.
Most terminals today have more than one emulation (personality or "terminal mode"). The terminal model numbers of terminals formerly made by DEC (Digital Equipment Corporation now Compaq) start with VT (e.g. VT100). Many other terminals which are not VT100 may be set up to emulate a VT100. Wyse was a major terminal manufacturer until about 2005. Most of their terminals can emulate various DEC terminals such at VT100 and VT220. Thus if you want to, say, use a VT320 terminal you may either use a real VT320 in "native" personality or possibly use some other terminal capable of emulating a VT320.
The "native" personalities usually have more capabilities so, other things being equal, "native" is usually the best to use. But other things may not be equal. Since the Linux console emulates a VT102 it you may want to have a terminal emulate this (or something close to it such as VT100). This will help insure that some programs that may not handle terminals properly will still work OK on your terminal. Some programs will assume that you are using a VT102 if the program can't find a terminfo for your terminal (or can't find a certain capability). Thus the failure of a program to work correctly with your non-vt102 terminal may well be your fault if you don't provide a good terminfo file for your terminal. Using "native" and then reporting any bugs will help discover and fix bugs which might not otherwise get detected.
The most common type of emulation is to use a PC like it was a vt100 terminal (or the like). Programs loaded into the PC's memory do the emulation. In Linux (unless you're in X Window) the PC monitor (called the console) emulates a terminal of type "Linux" (close to vt100). Even certain windows within X Window emulate terminals. See Terminal Emulation.
On a PC, the monitor is normally the console. It emulates a terminal of type "Linux". One logs on to it as a virtual terminal. See The Console. It receives messages from the kernel regarding booting and shutdown progress. One may have the messages that normally go to the console, go to the terminal. To get this you must manually patch the kernel, except that for kernel 2.2 (or higher) it is a "make config" option. See Make a Serial Terminal the Console.
"tty" is an abbreviation for "Teletype". The first terminals were Teletypes (like remotely controlled typewriters). See subsection Teletypes. A list of Linux devices (the stuff in the /dev directory) may be found in "Linux Allocated Devices" which should be included with kernel sources. It "describes" what each device used for in only a word or two but doesn't tell you how to use them.
The computer considers each serial port to be a "device". It's sometimes called a terminal device since at one time terminals were the most common use for a serial port. For each such serial port there is a special file in the /dev (device) directory. /dev/ttyS0) is the special file for the serial port known as COM1 in the DOS/Windows world.
To send text to a terminal you may redirect standard output of some command-line command to the appropriate special file. For example typing "echo test > /dev/ttyS1" at the command prompt should send the word "test" to the terminal on ttyS1 (COM2) provided you have write permission on /dev/ttyS1. Similarly, typing "cat my_file > /dev/ttyS0" will send the contents of the file my_file to COM1 (ttyS0).
Pseudo terminals are pairs of devices such as /dev/ptyp3 and /dev/ttyp3. There is no physical device directly associated with either of them, not even a serial port connector. But if a program treats ttyp3 like it was a serial port, what is read and written to that port appears on the other member of the pair ptyp3 which another program uses to read and write to. Thus two programs talk to each other via this method and one program on ttyp3 thinks it's talking to a serial port. It's something like a "pipe" between these two tty's.
For talking to ttyp3, any program designed to talk to a serial port will do. But for the other program that talks to ptyp3, it must have been specially written to talk to it. It's mainly programmers that must concern themselves with pseudo terminals and most users don't need to worry about them.
Here's an example: If someone connects via telnet to your computer over a network (you are a telnet server), the part of the telnet program handling this connection on your computer may wind up connected to the pseudo terminal ptyp2. A getty program should be running on the corresponding ttyp2. Getty thinks it's talking to a terminal. When telnet gets a character from the remote client, it goes thru ptyp2 to ttyp2 to getty which then sends back "login:" routed via ttyp2, ptyp2, your server telnet program, and then out to the network back to the client. Here the login program and the telnet server program talk to each other via a "pseudo terminal". Note that there is no pseudo terminal used on the client computer, just telnet. Of course the server allocates a pseudo terminal (on the server) for each client.
In X Window, the terminal emulator programs (such as xterm) use pseudo terminals. Ham radio programs under Linux also use them. By using certain application software, it is possible to have 2 or more pseudo terminals attached to the same physical serial port.
For a pseudo terminal pair such as ptyp3 and ttyp3, the pty... is the master or controlling terminal and the tty... is the slave.
There are only 16 ttyp's: ttyp0-ttypf (f is a hexadecimal digit). To get more pairs, more letters such as q, r, s are used instead of p. For example the pair ttys8, ptys8 is a pseudo terminal pair. Later on, even more letters were added so as to allow even more pseudo terminals. And when z was reached, they wrapped around to a. This is confusing but old habits are difficult to change. Today Linux allow say ttyp189 but it's not used. The device file system, which was abandoned in 2004, would have used tty/s189. Be sure not to type say ttys2 if you mean ttyS2 (a real serial port).
The master and slave are really the same "port" but the slave is used by the application program and the master is used by a network program (or the like) which supplies (and gets) data to/from the slave port. The program using the slave port can run "as is" since it thinks it is talking to a serial port.
Unix98 pseudo terminals (available on Linux) is more advanced than the above but the basic concepts are the same (only the device names and methods of creating them change). It creates pseudo terminal devices on request so there is no need to check if the pseudo terminal you might want to use in in use. By opening /dev/ptmx a new pseudo terminal pair is created. The master doesn't show up as a device but is just a file descriptor number passed to the computer program that opened /dev/ptmx. But the slave is put into the /dev/pts directory: for example" /dev/pts/3.
The /dev/pts directory is considered to be a file system of type devpts and appears in the lists of mounted filesystems. While the "file" /dev/pts/3 looks like an entry in the now obsolete device filesystem, /dev/pts Is really a wholly different kind of filesystem.
See the Linux manual pages "pty" and "pts" (Unix 98 style) for more details. For programmers there's the man-page openpty/forkpty (either name displays the same man-page) which assumes that you already understand pseudo terminals. There is a usr/include/pty.h file for use by programmers. In earlier versions of Linux there was a pty.o module, but it now seems that it's been built into the kernel. Here's an example of some options available when you are compiling a Linux 2.6 kernel:
CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
/dev/tty stands for the controlling terminal (if any) for the current process. To find out which tty's are attached to which processes use the "ps -a" command at the shell prompt (command line). Look at the "tty" column. For the shell process you're in, /dev/tty is the terminal you are now using. Type "tty" at the shell prompt to see what it is (see manual pg. tty(1)). /dev/tty is something like a link to the actually terminal device name with some additional features for C-programmers: see the manual page tty(4).
N stands for an integer. One use of these in Linux is with the ISDN driver package: isdn4linux. The ttyIN is something like ttySN but it emulates a modem and can be given modem commands.
In Linux the PC monitor is usually called the console and has several device special files associated with it: vc/0 (tty0), vc/1 (tty1), vc/2 (tty2), etc. When you log in you are on vc/1. To go to vc/2 (on the same screen) press down the 2 keys Alt(left)-F3. For vc/3 use Left Alt-F3, etc. These (vc/1, vc/2, vc/3, etc.) are called "virtual terminals". vc/0 (tty0) is just an alias for the current virtual terminal and it's where messages from the system are sent. Thus messages from the system will be seen on the console (monitor) regardless of which virtual terminal it is displaying.
You may log in to different virtual terminals and thus have a few different sessions with the computer going on at the same time. Only the system or the root user may write to /dev/vc/0 to which /dev/console is sometimes linked. For more info on the console see The Linux Console.
The /dev directory comes
supplied with many device special files. If you need something that's
not there you may try to create it with the "mknod" command. See the
manual page ttys(4) for how to do this for serial ports. To use
mknod you must know the major and minor device numbers. You
might be able to infer the numbers you need by using the "ls -l"
command in the /dev directory. It will display the major and minor
numbers of existing special files.
If you know almost nothing about terminals, it's suggested that you first read Introduction and also read Overview of How Terminals Work.
The terminal screen refreshes itself at perhaps 60 times per second from an image stored in the memory of the terminal. For a PC the monitor's image is stored on the video card inside the computer but for a terminal, the equivalent of the video card is inside the terminal. For a text terminal the storage of the image uses little memory. Instead of putting every dot (pixel) on the screen into memory and requiring the storage of about a quarter-million dots, a much more efficient method of storage is used.
A screen-full of text may be represented inside the terminal memory by ASCII bytes, one for each character on the screen. An entire screen only takes about 2K ASCII bytes. To display these characters, the terminal must also know the bit-map (the shape) of each of the almost 100 printable ASCII characters. With a bit-map of a character using say 15 bytes, only about 1.5K of memory is needed for the bit-maps of all the ASCII characters (the font). This ASCII text and font memory is scanned so that the resulting image is put on the screen about 60 times each second. This is a form of shared memory where a single bit-map of a letter such as the letter e, is shared by all of the many letter e's which appear on a screen-full of text. Low memory requirements meant low costs to produce monitors in the early 1980's when the cost of memory was several thousand times higher than it is today (costing then several dollars per kilobyte).
The first terminals were something like remotely controlled typewriters which could only "display" (print on paper) the character stream sent to them from the computer. The earliest models were called Teletypes. The name "tty" is just an abbreviation for "Teletype". Early terminals could do a line feed and a carriage return just like a typewriter and ring a bell when a bell character was received. Due to the lack of significant capabilities this was the first type of terminal to be labeled "dumb". This type of terminal interface (using a terminal type called "dumb") is sometimes used today when the computer can't figure out what kind of a terminal it is communicating with.
Terminals have many capabilities some of which are always present and some of which require commands from the computer to change or activate. To exercise all these capabilities under the control of the computer requires that special codes be established so that the computer can tell the terminal what to do. There are two major type of such codes: escape sequences and control codes (control characters). There are many times more escape sequences than control codes.
The control codes (or control characters) consist of the first 32 bytes of the ASCII alphabet. They include the following: carriage-return (cursor to far left), line-feed (cursor down one line), backspace, escape-character, tab, and bell. They do not normally show on the screen. There is usually a command which you may give to your terminal which will result in them being displayed when they are received by the terminal. It's called something like "Display Controls" or "Monitor". If you do this then the display may look a mess since escape sequences, which all start with the ESC (escape) control character, are no longer executed. Words which should appear at the top or bottom of the screen will show up in other locations. The escape sequences to reposition the cursor display on the screen but the cursor doesn't move to where the escape sequence says.
Since there are not nearly enough control codes to do everything (and for some reason, not all of them are utilized) many escape sequences are used. They consist of the "escape" (ESC) control character followed by a sequence of ordinary characters. Upon receiving an escape character, the terminal examines the characters following it so that it may interpret the sequence and carry out the intended command from the computer. Once it recognizes the end of a valid sequence, further characters received just display on the screen (unless they are control codes or more escape sequences). Some escape sequences may take parameters (or arguments) such as the coordinates on the screen to move the cursor to. The parameters become a part of the escape sequence. An Esc Sequence List is on the web for some terminals, but it's terse.
A list of the escape sequences for your terminal should be in the "programmers manual" for the terminal. Except for very old terminals, there may be two or three hundred such sequences. If you don't have a such manual it's not easy to find them. Some of the sequences are available on the Internet. One link is Esc Sequence List. By searching the Internet for one sequence (such as ESC[5m) you may come across a long list of them.
Another way to determine some of them is to find the terminfo entry (termcap) for the terminal and mentally decode it. See Terminfo and Termcap (detailed) in this document and/or the Termcap Manual on the Internet. Unfortunately, the terminfo (termcap) for a terminal often does not list all of the escape sequences which the terminal has available for use, but fortunately, the most important ones are usually there.
Terminals have various methods of generating character attributes such as bold, reverse-video, underlining, etc. There should be no need for the user to worry about how this is done, except that it creates problems for some old terminals and there is sometimes an option for this in the set-up menu of newer terminals.
The magic cookie method is obsolete. It's the simplest (and worst) method of defining attributes: Use a certain byte for the start of an attribute and another to end that attribute. For example, a "start underlining" magic cookie byte is placed just before the first word to be underlined. These extra bytes are put into the memory of the screen page, just like character bytes that display as characters. But this might foul up the count of the number of characters per line since non-printable magic cookie characters are intermingled with other printable characters. This sometimes causes problems.
A better method which uses more memory is to assign an attribute byte (or half=byte, etc.) to each displayed character. This method is used by PC video cards (for text) for the common PC monitor.
While the common monochrome terminal is not a color terminal it may have a fixed "color" display other than white such as green or amber. All terminals have black (electron beam turned off = zero brightness). A real color terminal can change the color of the text and background to many different colors while a monochrome terminal can only change the brightness of a fixed color.
However, changing the brightness, etc. gives a lot of possibilities. For example, a black and white (monochrome) terminal can have white, grey, and black by varying the brightness. Some words can be black on a light grey background while other are highlighted by black on white. In addition there is white on black, underlining, and blinking.
Color works like the color on a computer monitor or TV screen. The CRT has three colors of dots on it with each color controlled by its own electron beam (3 beams). Monochrome has inherently better resolution since it doesn't depend on dots permanently fixed on the screen. For text terminals the only use of color is to differentiate text and this advantage is not always worth the cost of worse resolution. Thus monochrome may be better since it also costs less.
For dual sessions the terminal has two serial ports of equal status. Each port is connected to a serial port on a different computer. Thus one may log in to two different computers with each session displaying in a split-screen window. Alternatively, each session may run full-screen with a "hot" key (or the like) to switch between sessions. One could also connect to two different serial ports on the same computer and log in twice (similar to "virtual terminals" at the console). The program "screen" will make any ordinary terminal (single session) connected to a single computer run two or more "sessions".
Many terminals have a connector on the rear for such a port. It may be labeled as "Aux" or "Printer", etc. Some printer ports are for parallel printers while others are for serial printers. If a printer is connected to the printer or auxiliary port, then pressing certain keys will print the screen. One may also have everything that displays on the screen go also to the printer. If the port is an auxiliary port, one may connect this to another computer and almost have dual sessions as above. However, the video memory inside the terminal may not retain both sessions so you may need to refresh the screen when switching to the other session. There will likely not be a hot key either but possibly a programmable function key may be programmed to do this. There exists various key combinations and escape sequences for controlling such a port. See Printer Esc.
There is a program called vtprint which is designed to send a
print job (text only) to your terminal to be printed on a printer
attached to the terminal. It's homepage is
vtprint. It's also
included in the Debian distribution of Linux. xprt (also in
Debian) seems to do something similar, but only for X Window terminals
??
Using the printer port to print may be useful if you don't have an extra port on your PC for a printer or for "point of sale" use in a store. "Transparent print mode" is where whatever the PC sends out to the terminal goes instead to the printer. If you want the printer to be able to send bytes to the PC (in the reverse direction) then (per Wyse) it's "bidirectional mode". The Wyse "auxiliary print mode" is just transparent print mode where the terminal screen monitors what's being printed.
Many terminals permit the storage of more than one page in their video memory. Sometimes the page size is the same as the screen, but sometimes it is larger so that scrolling will reveal unseen parts of a page. So when one looks at a screen, there may be hidden text on the same page above or below the display. In addition, if there is more than just one page, there may be hidden text on these other pages. One use for pages is on terminals that support dual sessions. Each session may have its own page and one may switch back and forth between them.
Even if you only have a one-page-terminal with the page sized equal to what is displayed on the screen, you will still see other pages of a file (etc.) as the host sends more data to the terminal. One advantage to having additional pages stored in the terminal memory is so that you can jump to them instantly without waiting a second or so for them to be transmitted from the host.
Multiple pages is supported by ncurses. There is also a commercial program called "Multiscreen" which supports multiple pages but probably not for Linux ?? Multiscreen is reported to be part of SCO and is something like the virtual terminals on a Linux PC console. The Linux program "screen" makes it look like you have multiple pages but they are stored in the computer and but you can have only one page-like window for each running program.
A character-set is normally represented by a list (or table or chart) of characters along with the byte code assigned to each character. The codes for a byte range from 0 to 255 (00 to FF in hexadecimal). In MS-DOS, character-set tables are called "code-pages". You should examine such a table if you're not familiar with them. They are sometimes included in printer and terminal manuals but also are found on the Internet.
Many character sets include letters from foreign languages. But they may also include special characters used to draw boxes and other special characters.
ASCII was the traditional English character set used on text terminals It is a 7-bit code but will usually work OK even if your terminal is set to 8-bit mode. In 8-bit mode with ASCII, the high order bit is always set to zero. Other character-sets are usually available and usually use 8-bit codes (except on very old terminals where the only choice is ASCII). The first half of most character-sets are the conventional 128 ASCII characters and the second half (with the high-order bit set to 1) belong to a wide variety of character-sets. Character sets are often ISO standards. To get specialized character sets on a terminal, you may need to download a soft-font for that character-set into the memory of the terminal. Many terminals have a number of built-in character sets (but perhaps not the one you need).
Here are some common 8-bit character sets. CP stands for Code Page character sets invented by IBM: CP-437 (DOS ECS), ISO-8859-1 (Latin-1), CP-850 (Multilingual Latin 1 --not the same as ISO Latin-1), CP-1252 (WinLatin1 = MS-ANSI). MS Windows uses CP-1252 (WinLatin1) while the Internet often uses Latin-1. There are several ISO-8859- character sets in addition to Latin-1. These include Greek (-7), Arabic (-6), Eastern European (-2), and a replacement for Latin-1 (-15) called Latin-9. There are many others. For example, KOI8-R is more commonly used for Russian than IS0-8859-5. Unicode is a very large character-set where each character is represented by 2 bytes instead on just one byte.
More info re character-sets are:
Once you've found the character set name (or alpha-numeric designation) you are interested in, you may search for more info about it on the Internet.
There are special characters for drawing boxes, etc. There are also numerous non-ASCII symbols such as bullets. These may either be part of an 8-bit character set (such as WinLatin1 = CP-1252) or provided as a separate font (in vt100 terminals). Your terminfo may be set up to use them. But if you see a row of letters when there should be a line, it may mean that terminfo hasn't implemented them.
You need to know the following if your graphics don't work right. The default graphic character set is the vt-100 ANSI graphics. Otherwise the string acsc must be defined in your terminfo. It establishes a map between the vt-100 graphic characters codes and the actual codes used on your terminal. So even if your terminal doesn't have the vt-100 graphics, it can likely still generate such graphics with some other character set. If terminfo has it right, this will happen automatically.
If character sets must be switched then the terminfo variables: enacs, rmacs, and smacs should be defined. Note acs = Alternate Character Set. Even if the upper half of the normal character set contains the graphic characters it may be considered a separate 7-bit character set that needs to be switched to.
In the 1960's, the ASCII 7-bit code was devised to map 7-bit bytes to English letters, numbers, punctuation marks, etc. Other countries adopted ASCII, but most of them had some additional letters which were not present in the ASCII code. What to do? Various people decided to purge certain symbols (such as ^, }) from ASCII and to substitute national letters (ones with dots over them, etc.) for the ASCII letters. In other words they replaced ASCII letters with "National Replacement Characters"
There were a lot of problems with this, since it was done mostly by companies which sold computer terminals with a resulting lack of standardization. Another problem was that sometimes the purged symbols were needed. This problem was solved in the 1980's and 1990's with the adoption of 8-bits/byte character sets which had many more letters.
Many West-European languages only needed several additional letters
which were not in ASCII. To get them in 7-bit code, they borrowed the
codes for seldom used ASCII symbols:
@ [ \ ] ^ ` { \
} ~
The symbols $ and # are sometimes used also. So
when using these replacement character sets, you are deprived of using
certain of these ASCII symbols since they now are used for the new
non-ASCII letters. Now that 8-bit character codes have replaced 7-bit
ones, it's better to use an 8-bit code which has both all the ASCII
symbols plus the non-ASCII characters for various languages. There's
also Unicode which replaces 8-bit codes with the same code scheme to
cover all languages (well almost all significant ones).
ISO-646 (for 1972 and later) permitted using National Replacement Characters (7-bit). It specified that the above mentioned character codes may be borrowed, but doesn't specify which national characters are to replace them. Some countries standardized the replacements by registering them with ECMA.
Many terminals exist which support these national replacement characters but you probably don't want to implement this support unless you have some old files to read. Very old terminals may only support the national characters for the country in which they were sold. Later terminals offered a choice of languages. Modem terminals are 8-bit and don't need "national replacements". Replacement characters exist for the following languages/countries: British, Cuba (Spanish), Dutch, Finnish, French, French Canadian, German, Hebrew, Hungarian, Italian, Norwegian/Danish, Portuguese, Spanish, Swedish, Swiss (German).
Here's tables for some character sets taken from Kermit and Unisys documents:
Swedish Danish
ASCII German Finnish Norwegian French
@ at-sign section ------- ------- a-grave
[ left-bracket A-diaeresis A-diaeresis AE-digraph degree
/ backslash O-diaeresis O-diaeresis O-slash c-cedilla
] right-bracket U-diaeresis A-circle A-circle section
^ circumflex ------ U-diaeresis ------- -------
` accent-grave ------ e-acute ------- -------
{ left-brace a-diaeresis a-diaeresis ae-digraph e-acute
| vertical-bar o-diaeresis o-diaeresis o-circle u-grave
} right-brace u-diaeresis a-circle a-circle e-grave
~ tilde ess-zet u-diaeresis -------- diaeresis
ASCII Italian Spanish
@ at-sign section section
[ left-bracket degree inverted-exclamation
/ backslash #-pound N-tilde
] right-bracket e-acute inverted-question-mark
^ circumflex ------- -------
` accent-grave u-grave -------
{ left-brace a-grave degree
| vertical-bar o-grave n-tilde
} right-brace e-grave --------
~ tilde i-grave --------
Most terminals made after the mid 1980's can accept downloaded
soft-font. This means that they can display almost any character set
provided that you can find the soft-font for it. If you can't find
the needed soft-font, you can always create your own. A free font
editor for this is called BitFontEdit (written by the author of this
document) and is at at
http://www.ibiblio.org/pub/Linux/utils/terminal/
For mapping the keyboard (and screen) for use of various fonts see
Character Mapping: mapchan
Terminal keyboards often have a number of keys that one doesn't find on a PC keyboard. Few (if any) actual terminals will have all of these keys and most will have additional keys not listed here. Some have a large number of special purpose keys such as terminals made for use with cash registers. There are often many more key meanings than shown here since these keys often have extended meanings when used in conjunction with other keys (such as shift and control).
A few text-terminals support a mouse. When the mouse is clicked, an escape sequence is sent to the host to tell it where the mouse is. For a mouse on VT terminals see http://www.cs.utk.edu/~shuford/terminal/dec_vt_mouse.html These escape codes for mice are called "DEC Locator sequences". The FALCO Infinity Series of terminals, model ANSI-G supports it. Do any linux applications support this ??
Since a PC has a screen and keyboard (as does a real terminal) but also has much more computing power, it's easy to use some of this computing power to make the PC computer behave like a real text terminal. This is one type of terminal emulation. Another type of terminal emulation is where you set up a real terminal to emulate another brand/model of terminal. To do this you select the emulation you want (called "personality" in Wyse jargon) from the terminal's set-up menu. Still a third type is where you just use a text-based interface (at the console) to your Linux PC, either by a terminal screen in Xwindow or by a "virtual terminal". This section only covers the first case.
To fully emulate a real terminal on a PC requires that a serial port of the computer will be used to connect the emulated terminal to another computer. This would be either with a direct cable connection from serial port to serial port, or via a modem. But in other cases, the serial port will not be used directly as the interface. Instead, the interface may be a network and the flow of bytes to and from the terminal will travel in network packets via either a modem on a serial port or via an ethernet port.
Emulation for connection to a remote computer provides more that just a real text-terminal since the PC doing the emulation can also do other tasks at the same time it's emulating a terminal. For example, for serial port connections, kermit or zmodem may be run on the PC to enable transfer of files over the serial line (and possibly over the phone line via a modem) to the other computer that you are connected to. The emulation needs only to be run on one of the virtual consoles of the PC, leaving the other virtual consoles available for using the PC in command-line-interface.
For Linux see Make a Linux PC a serial port terminal. Emulation software for this also available for use under MS Windows. See Make a non-Linux PC a terminal This can be used to connect a Windows PC (as a Text-Terminal) to a Linux PC.
Most Linux free software can only emulate a VT100, VT102, or VT100/ANSI, or Wyse60 (but not fully). Since most PC's have color monitors while VT100 and VT102 were designed for a monochrome monitor, the emulation usually adds color capabilities (including a choice of colors). Sometimes the emulation is not 100% perfect but this usually causes few problems. None of them provide programmable function keys. The non-free emulation software running under MS Windows can emulate many more terminals than free Linux can.
Some have erroneously thought that they could create an emulator at a Linux console (monitor) by setting the environment variable TERM to the type of terminal they would like to emulate. This does not work. The value of TERM only tells an application program what terminal you are using. This way it doesn't need to interactively ask you this question. If you're at a Linux PC monitor (command line interface) it's a terminal of type "Linux" and since you can't change this TERM must be set to "Linux". This should happen without you needing to do anything.
If you set it to something else you are fibbing to an application program. As a result, it will incorrectly interpret certain escape sequences from the console resulting in a corrupted interface. Since the Linux console behaves almost like a vt100 terminal, it could still work almost OK if you falsely claimed it was a vt100 (or some other terminal which is close to a vt100). In this case it may seeming work OK most of the time but once in a while will make a mistake.
Dialing programs for making a PPP connection to the Internet such as wvdial, don't normally include any terminal emulation. But some other programs (such as minicom or seyon) do both terminal emulation and modem dialing (without PPP so it's not easy to use them to connect to the internet). The program "picocom" just does terminal emulation although it's possible to type in a modem command and a phone number to dial out manually. These programs are also useful for testing modems. Seyon is only for use with X Window and can emulate Tektronix 4014 terminals. In the past one could use them to dial up some public libraries to use their catalogs and indexes, (or even read magazine articles on line). But today it's done on the Internet.
The communication program C-Kermit (sometimes just called kermit) doesn't do terminal emulation for Linux (in 2006). But Kermit can emulate many terminals in its non-free MS Windows versions so you`ll see lots of claims that Kermit can do terminal emulation. With Linux, it's merely a semi-transparent pipe between whatever terminal you are on and the remote site you are connected to. Thus if you use kermit on a Linux PC the terminal type will be "Linux". If you have a Wyse60 connected to your PC and run kermit from that, you will appear as a Wyse60 to the remote computer (which may not be able to handle Wyse60 terminals). Minicom emulates a VT102 and if you use it on Wyse60 terminal vt102 the remote host will think you are a vt102 and send you vt102 escape sequences. These will flow into your computer's serial port and will get translated to the Wyse escape sequences before going out another serial port on your computer to your Wyse60 terminal. C-Kermit can't do this sort of thing.
Emulators exist under DOS such as telix and procomm work
just as well. The terminal emulated is often the old VT100, VT102, or
ANSI (like VT100).
There are many terminal emulation programs (such as xterm, uxterm. gnome-terminal, and konsole) which may be run under X Window. They can usually emulate a VT102, but some may be able to emulate at VT220, or Tektronix 4014. They provide a command line interface to the computer but they don't communicate via the serial port like a text terminal. See Ubuntu -- x-terminal-emulator for a brief list of such emulators. Some are multilingual. Your Linux distribution has likely installed one for you.
Unless you are using X Window with a large display, a real terminal is often nicer to use than emulating one. It often has better resolution for text (since it's monochrome), and has no disk drives to make annoying noises.
For the VT series terminals there is a test program: vttest
to help determine if a terminal behaves correctly like a vt53, vt100,
vt102, vt220, vt320, vt420 etc. There is no documentation but it has
menus and is easy to use. To compile it run the configure script and
then type "make". It may be downloaded from:
http://www.ibiblio.org/pub/Linux/utils/console/
The console for a PC Linux system is normally the computer monitor in text mode. It emulates a terminal of type "Linux" and the escape sequences it uses are in the man page: console_codes. There is no way (unless you want to spend weeks rewriting the kernel code) to get it to emulate anything else. Setting the TERM environment variable to any type of terminal other than "Linux" will not result in emulating that other terminal. It will only result in a corrupted interface since you have falsely declared (via the TERM variable) that your "terminal" is of a type different from what it actually is: Linux. See Don't Use TERM For Emulation
In X Window, using a terminal emulator give you the equivalent of a console and for the KDE they chose to call this emulation "konsole". In some cases, the console for a Linux PC is a text-terminal. One may recompile Linux to make a terminal receive most of the messages which normally go to the console. See Make a Serial Terminal the Console.
The "Linux" emulation of the monitor is flexible and has features which go well beyond those of the vt102 terminal which it was intended to emulate. These include the ability to use custom fonts and easily re-map the keyboard. These extra features reside in the console driver software (including the keyboard driver). The console driver only works for the monitor and will not work for a real terminal even if it's being used for the console. Thus the "console driver" is really a "monitor driver". In the early days of Linux one couldn't use a real terminal as the console so "monitor" and "console" were once always the same thing.
The stty commands work for the monitor-console just like it was a real terminal. They are handled by the same terminal driver that is used for real terminals. Bytes headed for the screen first go thru the terminal (tty) driver and then thru the console driver. For the monitor some of the stty commands don't do anything (such as setting the baud rate). You may set the monitor baud rate to any allowed value (such as a slow 300 speed) but the actual speed of putting text on the monitor screen will not actually change. The file /etc/ioctl.save stores stty settings for use only when the console is in single user mode (but you are normally in multiuser-user mode). This is explained (a little) in the init man page.
Many commands exist to utilize the added features provided by the console-monitor driver. Real terminals, which use neither scan codes nor VGA cards, unfortunately can't use these features. To find out more about the console see the Keyboard-and-Console-HOWTO. Also see the various man pages about the console (type "man -k console"). Unfortunately, much of this documentation is outdated.
Emulators often don't work quite right so before purchasing software you should try to throughly check out what you will get.
Unless you want to emulate the standard vt100 (or close to it) or a Wyse 60, there doesn't seem to be much free terminal emulation software available for Linux. The free programs minicom, picocom, and seyon (only for X Window) can emulate a vt100 (or close to it). Seyon can also emulate a Tektronix 4014 terminal. See Wyse 60 emulator. gtkterm doesn't use escape sequences, and might be said to emulate a terminal of type "dumb" so it would be quite slow if used as a text terminal for editing, etc. It's simple to set up, very weak in capabilities, but it does show its current status at the bottom of the screen.
Minicom, picocom, or gtkterm may be used to emulate a directly connected terminal by simply starting one of them. For minicom, you must configure it for the serial port used). Picocom is like a mini-minicom, doesn't have automatic dialout capability. Gtkterm might be called a "mini-mini-minicom".
Skip this paragraph if you use picocom. For the case of minicom you obviously don't try to dial-out. When you want to quit minicom (after you logout from the other PC) you use minicom's q command to quit without reset since there is no modem to reset. When minicom starts, it automatically sends out a modem init string to the serial port. But since there's no modem there, the string gets put after the "login:" prompt. If this string is mostly capital letters, the getty program (which runs login) at the other PC may think that your terminal has only capital letters and try to use only capital letters. To avoid this, configure the modem init strings sent by minicom to null (erase the init strings).
The non-free terminal emulator "Procomm" (which is from the MS world), can be used on a Linux PC if you run dosemu to emulate Dos or possibly in a mode emulating MS Windows. The last version of it seems to be 4.8 released in around 2000 so it will likely not work with modern MS systems. It was sold by Symantec which has many files supporting it which may be found using their search engine at http://www.symantec.com/. And if you check the Internet (in 2008), it's still being sold here and there.
There's a specialized Linux distribution: Serial Terminal Linux. It will turn a PC to into a minicom-like terminal. It's small (fits on a floppy) and will not let you use the PC for any other purpose (when it's running). See http://www.eskimo.com/~johnnyb/computers/stl/. It will let you have more than one session running (similar to virtual terminals), one for each serial port you have.
TERM (non-free commercial software from Century Software) Terminal Emulator can emulate Wyse60, 50; VT 220, 102, 100, 52: TV950, 925, 912; PCTERM; ANSI; IBM3101; ADM-1l; WANG 2110. Block mode is available for IBM and Wyse. It runs on a Linux PC.
This happens automatically when you run programs like telnet or ssh, provided of course that your computer is connected to a network (perhaps via a modem). Telnet normally uses a network (often the Internet) to connect your console, which emulates a terminal of type "Linux", to a remote computer for you to log in to. However, there are some free programs that allow you to use telnet with IBM terminal emulation on your PC to connect with IBM mainframes.
One IBM program emulates an IBM tn5250 terminal and printer and another emulates an IBM c3270. There's also one that emulates an IBM pr3287 printer (the mainframe thinks it's connected to the printer). The Debian distribution has these. It's reported that the tn5250 emulates a vt keyboard under Linux and not a 5250 keyboard like it should. Also, it's reported that the documentation and keyboard mapping for the MS Windows version are better than for the Linux version.
Emulators exist which run on non-Linux PCs. They permit you to use a non-Linux-PC as a terminal connected to a Linux-PC. Under DOS there were many programs that not only emulated a terminal but let you dial out with a modem so that you could connect to other computers over telephone lines (without getting connected to the Internet). Of historical interest is DOS Serial Communications (1994).
Today Windows comes with "HyperTerminal" (formerly simply called "Terminal" in Windows 3.x and DOS). Competing with this is "HyperTerminal Private Edition" http://www.hilgraeve.com/htpe/index.html which is non-free to business. It can emulate vt-220. The Windows "terminals" are intended for calling out with a modem but they should also work as directly connected terminals?? Turbosoft's TTWin can emulate over 80 different terminals under Windows. See http://www.ttwin.com/ or http://www.turbosoft.com.au/ (Australia). See also WRQ
For using a Mac computer to emulate a common terminal use either Linux's "minicom" (ported to the Mac OS X) or the old "zterm" (shareware). For very old Macs prior to OS X, see the mini-howto: Mac-Terminal. Carnation Software has non-free software to emulate a wide variety of terminals on a Mac. Mac OS X has a "terminal" program that gives you a terminal window just like the xterm window in Linux's X Window. In that window you may run "minicom" (if it's available). Both the "fink" and "darwinports" projects have ported minicom to the Mac, but they may not have the most recent version and you might need to compile minicom yourself.
One place to check terminal emulation products is Shuford's site, but it seems to lists old products (which may still work OK). The fact that most only run under DOS (and not Windows) indicates that this info is dated. See http://www.cs.utk.edu/~shuford/terminal/term_emulator_products.txt.
Flow control (= handshaking = pacing) is to prevent too fast of a flow of bytes from overrunning a terminal, computer, modem or other device. Overrunning is when a device can't process what it is receiving quickly enough and thus loses bytes and/or makes other serious errors. What flow control does is to halt the flow of bytes until the terminal (for example) is ready for some more bytes. Flow control sends its signal to halt the flow in a direction opposite to the flow of bytes it wants to stop. Flow control must both be set at the terminal and at the computer.
There are 2 types of flow control: hardware and software (Xon/Xoff or DC1/DC3). Hardware flow control uses dedicated signal wires such as RTS/CTS or DTR/DSR while software flow control signals by sending DC1 or DC3 control bytes in the normal data wires. For hardware flow control, the cable must be correctly wired.
The flow of data bytes in the cable between 2 serial ports is bi-directional so there are 2 different flows (and wires) to consider:
You might ask: "Why not send at a speed slow enough so that the device will not be overrun and then flow control is not needed?" This is possible but it's usually significantly slower than sending faster and using flow control. One reason for this is that one can't just set the serial port baud rate at any desired speed such as 14,500, since only a discrete number of choices are available. The best choice is to select a rate that is a little higher than the device can keep up with but then use flow control to make things work right.
If one decides to not use flow control, then the speed must be set low enough to cope with the worst case situation. For a terminal, this is when one sends escape sequences to it to do complex tasks that take more time than normal. In the case of a modem (with data compression but no flow control) the speed from the computer to the modem must be slow enough so that this same speed is usable on the phone line, since in the worst case the data is random and can't be compressed. If one failed to use flow control, the speed (with data compression turned on) would be no faster than without using any compression at all.
Buffers are of some help in handling worst case situations of short duration. The buffer stores bytes that come in too fast to be processed at once, and saves them for processing later.
Another way to handle a "worst case" situation (without using flow control or buffers) is to add a bunch of nulls (bytes of value zero) to escape sequences. Sometimes DEL's are used instead provided they have no other function. See Recognize Del.
The escape sequence starts the terminal doing something, and while the
terminal is busy doing it, it receives a bunch of nulls which it
ignores. When it gets the last null, it has completed its task and is
ready for the next command. This is called null padding. These nulls
formerly were called "fill characters". These nulls are added just to
"waste" time, but it's not all wasted since the terminal is usually
kept busy doing something else while the nulls are being received. It
was much used in the past before flow control became popular. To be
efficient, just the right amount of nulls should be added and figuring
out this is tedious. It was often done by trial and error since
terminal manuals are of little or no help. If flow control doesn't
work right or is not implemented, padding is one solution. Some of
the options to the stty command involve padding.
One might wonder how overrunning is possible at a serial port since both the sending and receiving serial ports involved in a transmission of data bytes are set for the same speed (in bits/sec) such as 19,200. The reason is that although the receiving serial port electronics can handle the incoming flow rate, the hardware/software that fetches and processes the bytes from the serial port sometimes can't cope with the high flow rate.
One cause of this is that the serial port's hardware buffer is quite small. Older serial ports had a hardware buffer size of only one byte (inside the UART chip). If that one received byte of data in the buffer is not removed (fetched) by CPU instructions before the next byte arrives, that byte is lost (the buffer is overrun). Newer UART's, namely most 16550's, have 16-byte buffers (but may be set to emulate a one-byte buffer) and are less likely to overrun. It may be set to issue an interrupt when the number of bytes in its buffer reaches 1, 4, 8, or 14 bytes. It's the job of another computer chip (usually the main CPU chip for a computer) to take these incoming bytes out of this small hardware buffer and process them (as well as perform other tasks).
When contents of this small hardware receive buffer reaches the specified limit (one byte for old UART'S) an interrupt is issued. Then the computer interrupts what it was doing and software checks to find out what happened. It finally determines that it needs to fetch a byte (or more) from the serial port's buffer. It takes these byte(s) and puts them into a larger buffer (also a serial port buffer) that the kernel maintains in main memory. For the transmit buffer, the serial hardware issues an interrupt when the buffer is empty (or nearly so) to tell the CPU to put some more bytes into it to send out.
Terminals also have serial ports and buffers similar to the computer. Since the flow rate of bytes to the terminal is usually much greater than the flow in the reverse direction from the keyboard to the host computer, it's the terminal that is most likely to suffer overrunning. Of course, if you're using a computer as a terminal (by emulation), then it is likewise subject to overrunning.
Risky situations where overrunning is more likely are: 1. When another process has disabled interrupts (for a computer). 2. When the serial port buffer in main (or terminal) memory is about to overflow.
When its appears that the receiver is about to be overwhelmed by incoming bytes, it sends a signal to the sender to stop sending. That is flow control and the flow control signals are always sent in a direction opposite to the flow of data which they control (although not in the same channel or wire). This signal may either be a control character (^S = DC3 = Xoff) sent as an ordinary data byte on the data wire (in-band signalling), or a voltage transition from positive to negative in the dtr-to-cts (or other) signal wire (out-of-band signalling). Using Xoff is called "software flow control" and using the voltage transition in a dedicated signal wire (inside the cable) is called hardware flow control.
With terminals, the most common case of "stop sending" is where the terminal can't keep up with the characters being sent to it and it issues a "stop" to the PC. Another case of this is where someone presses control-S. Much less common is the opposite case where the PC can't keep up with your typing speed and tells the terminal to stop sending. The terminal "locks" its keyboard and a message or light should inform you of this. Anything you type at a locked keyboard is ignored. When the PC catches up on it's work, then the keyboard should unlock. When it doesn't, there is likely some sort of deadlock going on.
Another type of keyboard lock happens when a certain escape sequence (or just the ^O control character for Wyse 60) is sent to the terminal. While the previous type of lock is done by the serial driver, this type of lock is done by the hardware of a real terminal. It's a catch-22 situation if this happens since you can't type any commands to escape out of this lock. Going into setup and resetting might work (but it failed on my Wyse 60 and I had to cycle power to escape). One could also send an "unlock keyboard" escape sequence from another terminal.
The term "locked" is also sometimes used for the common case of where the computer is told to stop sending to a terminal. The keyboard is not locked so that whatever you type goes to the computer. Since the computer can't send anything back to you, characters you type don't display on the screen and it may seem like the keyboard is locked. Scrolling is locked (scroll lock) but the keyboard is not locked.
When the receiver has caught up with its processing and is ready to receive more data bytes it signals the sender. For software flow control this signal is the control character ^Q = DC1 = Xon which is sent on the regular data line. For hardware flow control the voltage in a signal line goes from negative (negated) to positive (asserted). If a terminal is told to resume sending the keyboard is then unlocked and ready to use.
Some older terminals have no hardware flow control while others used a wide assortment of different pins on the serial port for this. For a list of various pins and their names see Standard Null Modem Cable Pin-out. The most popular pin to use seems to be the DTR pin (or both the DTR pin and the DSR pin).
Linux PC's use RTS/CTS flow control, but DTR/DSR flow control (used by some terminals) behaves similarly. DTR flow control (in one direction only and also used by some terminals) is only the DTR part of DTR/DSR flow control.
RTS/CTS uses the pins RTS and CTS on the serial (EIA-232) connector. RTS means "Request To Send". When this pin stays asserted (positive voltage) at the receiver it means: keep sending data to me. If RTS is negated (voltage goes negative) it negates "Request To Send" which means: request not to send to me (stop sending). When the receiver is ready for more input, it asserts RTS requesting the other side to resume sending. For computers and terminals (both DTE type equipment) the RTS pin sends the flow control signal to the CTS pin (Clear To Send) on the other end of the cable. That is, the RTS pin on one end of the cable is connected to the CTS pin at the other end.
For a modem (DCE equipment) it's a different scheme since the modem's RTS pin receives the signal and its CTS pin sends. While this may seem confusing, there are valid historical reasons for this which are too involved to discuss here.
Terminals usually have either DTR or DTR/DSR flow control. DTR flow control is the same as DTR/DSR flow control but it's only one-way and the DSR pin is not used. For DTR/DSR flow control at a terminal, the DTR signal is like the signal sent from the RTS pin and the DSR pin is just like the CTS pin.
Some terminals use only DTR flow control. This is only one-way flow control to keep the terminal from being overrun. It doesn't protect the computer from someone typing too fast for the computer to handle it. In a standard file-transfer serial cable the DTR pin at the terminal is connected to the DSR pin at the computer. But Linux doesn't support DTR/DSR flow control (although drivers for some multiport boards may support DTR/DSR flow control.) A way around this problem is to simply wire the DTR pin at the terminal to connect to the CTS pin at the computer and set RTS/CTS flow control (stty crtscts). The fact that it's only one way will not affect anything so long as the host doesn't get overwhelmed by your typing speed and drop RTS in a vain attempt to lock your keyboard. See Keyboard Lock. For DTR/DSR flow control (if your terminal supports this two-way flow control) you do the above. But you also connect the DSR pin at the terminal to the RTS pin at the computer. Then you are protected if you type too fast.
What is confusing is that there is the original use of RTS where it means about the opposite of the previous explanation above. This original meaning is: I Request To Send to you. This request was intended to be sent from a terminal (or computer) to a modem which, if it decided to grant the request, would send back an asserted CTS from its CTS pin to the CTS pin of the computer: You are Cleared To Send to me. Note that in contrast to the modern RTS/CTS bi-directional flow control, this only protects the flow in one direction: from the computer (or terminal) to the modem.
For older terminals, RTS may have this meaning and goes high when the terminal has data to send out. The above use is a form of flow control since if the modem wants the computer to stop sending it drops CTS (connected to CTS at the computer) and the computer stops sending.
Old hard-copy terminals may have a reverse channel pin (such as pin 19) which behaves like the RTS pin in RTS/CTS flow control. This pin but will also be negated if paper or ribbon runs out. It's often feasible to connect this pin to the CTS pin of the host computer. There may be a dip switch to set the polarity of this signal.
Some think that hardware flow control is done by hardware but only a small part of it is done by hardware. Most of it is actually done by your operating system software. UART chips and associated hardware usually know nothing at all about hardware flow control. When a hardware flow control signal is received (due to the signal wire flipping polarity) the h