Text-Terminal-HOWTO-10.html0000644000160500001440000005216512117203375014577 0ustar gfergusers Text-Terminal-HOWTO: Terminal Emulation (including the Console) Next Previous Contents

10. Terminal Emulation (including the Console)

10.1 Intro to Terminal Emulation

A trivial 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. This section will not discuss this case.

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. Still a third type is where you just use a text-based interface (at the console --usually just the monitor) to your Linux PC, either by a terminal screen (such as xterm) in Xwindow or by a "virtual terminal".

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, xterm, pterm, 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.

10.2 Don't Try to Use TERM Variable for Emulation

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 (and it's too dumb to be able to probe the terminal to find out what type it is). 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". But this "Linux" should be set automatically, 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 give errors.

10.3 Serial Communication programs

while the newer free PuTTY and Terra-Term programs can connect directly to a serial line but can't dial out, most of of the older programs did dialing out via a serial port modem. Some dialing programs are for making a PPP connection to the Internet via a modem, such as wvdial, and 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). But since these programs connect to a modem via a specified serial port (including "internal" serial ports that have no connector on the back of the PC), they may be used to connect to a serial line via a possible serial port connector on the back of a PC. For this case you just set them up to connect without dialing a phone number. 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 (before the Internet was widespread) one could use dialing programs to dial up some public libraries to use their catalogs and indexes, or even read magazine articles on line. But today such activity is almost always done using the Internet where there is a much larger choice of connections and no long-distance telephone bills.

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).

Emulation under X Window

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.

Real terminals once were better

Unless one was using X Window with a large display, a real terminal was often nicer to use than emulating one. It often had better resolution for text (since it's monochrome), and had no disk drives to make annoying noises. Today, the resolution of modern color displays is better than that of the old text-terminals and disk drives are quieter.

10.4 Testing Terminal Emulation

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/

10.5 The Linux 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 to make this interface emulate anything else. But of course you can run emulation software on your PC so that the monitor and keyboard will emulate a text terminal while that software program is running. 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 gives you the equivalent of a console. For 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.

10.6 Emulation Software

Since there are free programs to emulate the most common terminals, you will unlikely need to use any non-free software. But if you need to purchase software you should try to throughly check out what other customers have to say about it.

Make a Linux PC a serial port terminal

Unless you want to emulate the standard vt100 (or close to it), xterm, or a Wyse 60, there doesn't seem to be much free terminal emulation software available for Linux. The free programs are minicom, picocom, and for GUI: seyon and PuTTY. Seyon can emulate either xterm or vt100 while PuTTy uses its own termcap (terminfo) named "putty" (put the terminal type "putty" in /etc/inittab). Putty's "pterm" can be used as a replacement for xterm.

PuTTY is much newer than most other emulations and a major use of it is as an SSH client but you can set its configuration for a serial port connection. Seyon is much older but with more features (some of which are seldom needed). There are also more recent (but weaker) "emulators" for a GUI interface: gtkterm and cutecom, neither of which can emulate any terminal except of type "dumb" ??). Seyon can also emulate a Tektronix 4014 terminal. For Wyse see Wyse 60 emulator.

Both gtkterm (and likely cutecom) don't use escape sequences, and might be said to emulate a terminal of type "dumb" so they would be quite slow if used as a text terminal for editing files on the host computer using the vim editor, etc. gtkterm is simple to set up and very weak in capabilities but it does show its current status at the bottom of the screen.

Minicom, PuTTY, picocom, gtkterm, or cutecom 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 and doesn't have automatic dialout capability. Gtkterm might be called a "mini-mini-minicom".

Minicom : 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 was a specialized Linux distribution: Serial Terminal Linux. It would 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). The link to it is broken, but one similar to it (in 2013), but on CD, is ASASHI DOT NET: PITUX, micro SERIAL TERMINAL LINUX

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.

Make a Linux PC an IBM network terminal

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.

Make a non-Linux PC a terminal

Emulators exist which run on non-Linux PCs. They permit you to use a non-Linux-PC as a terminal to 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 an article in Byte magazine from Feb 1994 entitled "DOS Serial Communications. It was onetime at http://www.byte.com/art/9402/sec8/art1.htm.

Today Windows comes with "HyperTerminal" (formerly simply called "Terminal" in Windows 3.x and DOS). Competing with this is both the free (open source) PuTTY and the non-free "HyperTerminal Private Edition" http://www.hilgraeve.com/htpe/index.html which is non-free to business. It can emulate vt-220. PuTTY emulates xterm and supposedly also vt-102 but it doesn't have file transfer capabilities (such as zmodem) like HyperTerminal does. But PuTTY permits a display with a height of over 24 lines (set the Linux shell variable LINES to say 32 by typing: LINES=32). Turbosoft's TTWin (non-free) 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 PuTTY, 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.

10.7 Colors on Emulated Terminals

Since displays used for text terminal emulation are almost always color displays, you can utilize color coding of words. Besides displaying directories this way (See Example for ls Function) some other Linux programs display color-coded text. It seems to mostly happen without any configuring but there may be color conflicts. For example, if you have set the background color green, then if a programs sends you green text, it will be difficult or impossible to read.

Color usually works by programs sending ANSI escape sequences to the terminal. One might think that an emulated terminal would show the ANSI escape codes in the terminfo. for the terminal. But this is not usually the case since if a terminal support colors it seems to be assumed that these color will be sent to the terminal using the ANSI encoding.

If you want to see what these encodings are, look at "man console_codes". The ECMA-48 color codes in this man page appear to be a subset of the ANSI color codes. For excruciating details see ANSI escape code - Wikipedia. Note that these ANSI codes cover more than just colors.

For PuTTY one can select the precise color to display for every ANSI code by using the settings menu and clicking on "Colours". For example if you have your screen background light green, then you can remap that ANSI color to some shade of brown that you select. Note that light green is called "Green Bold". It's bold because it contains a lot of white which makes it a light color.

Next Previous Contents Text-Terminal-HOWTO-11.html0000644000160500001440000004223312117203375014573 0ustar gfergusers Text-Terminal-HOWTO: Flow Control (Handshaking) Next Previous Contents

11. Flow Control (Handshaking)

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:

  1. Byte flow from the computer to the terminal
  2. Byte flow from the terminal keyboard to the computer.

11.1 Why Is Flow Control Needed ?

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.

11.2 Padding

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.

11.3 Overrunning a Serial Port

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.

11.4 Stop Sending

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.

11.5 Keyboard Lock

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.

11.6 Resume Sending

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.

11.7 Hardware Flow Control (RTS/CTS etc.)

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).

RTS/CTS, DTR, and DTR/DSR Flow Control

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.

Connecting up DTR or DTR/DSR Flow Control

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.

Old RTS/CTS handshaking is different


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.

Reverse Channel

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.

11.8 Is Hardware Flow Control Done by Hardware ?

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 hardware gives an electrical interrupt signal to the CPU. However, the hardware has no idea what this interrupt means. The CPU stops what it was doing and jumps to a table in main memory that tells the CPU where to go to find a program which will find out what happened and determine what to do about it. In this case this program stops the outgoing flow of bytes.

But even before this program stops the flow, it was already stopped by the interrupt which interrupted the work of the CPU. This is one reason why hardware flow control stops the flow faster. It doesn't need to wait for a program to do it. But if that program didn't command that the flow be stopped, the flow would resume once that program exited. So the program is essential to stop the flow even though it is not the first to actually stop the flow. After the interrupt happens any bytes (up to 16) which were already in the serial port's hardware transmit buffer will still get transmitted. So even with hardware flow control the flow doesn't instantly stop.

Using software flow control requires that each incoming byte be checked to see if it's an "off" byte. These bytes are delayed by passing thru the 16-byte receive buffer. If the "off" byte was the first byte into this buffer, there could be a wait while 15 more bytes were received. Then the 16 bytes would get read and the "off" byte found. This extra delay doesn't happen with hardware flow control.

11.9 Obsolete ?? ETX/ACK or ENQ/ACK Flow Control

This is also software flow control and requires a device driver that knows about it. Bytes are sent in packets (via the async serial port) with each packet terminated by an ETX (End of Text) control character. When the terminal gets an ETX it waits till it is ready to receive the next packet and then returns an ACK (Acknowledge). When the computer gets the ACK, it then send the next packet. And so on. This is not supported by Linux ?? Some HP terminals use the same scheme but use ENQ instead of ETX.

Next Previous Contents Text-Terminal-HOWTO-12.html0000644000160500001440000011577012117203375014603 0ustar gfergusers Text-Terminal-HOWTO: Physical Connection Next Previous Contents

12. Physical Connection

12.1 Introduction


12.2 Multiport I/O Cards (Adapters)


12.3 Direct Serial Cable Connection.



Pin numbering




  PC male DB25                          Terminal DB25
    TxD   Transmit Data       2 --> 3       RxD   Receive Data
    RxD   Receive Data        3 <-- 2       TxD   Transmit Data
    SG    Signal Ground       7 --- 7       SG    Signal Ground


        PC DB9                                 Terminal DB25
    RxD   Receive Data        2 <-- 2            TxD   Transmit Data
    TxD   Transmit Data       3 --> 3       RxD   Receive Data
    SG    Signal Ground       5 --- 7       SG    Signal Ground


        PC DB9                                 Terminal DB9
    RxD   Receive Data        2 <-- 3            TxD   Transmit Data
    TxD   Transmit Data       3 --> 2       RxD   Receive Data
    SG    Signal Ground       5 --- 5       SG    Signal Ground


Standard Null Modem cable pin-out (7 conductor)


PC male DB25                            Terminal DB25
DSR   Data Set Ready        6 <--|
                               |--> 6     DSR   Data Set Ready


PC DB9                                  Terminal DB25
                               |--> 6     DSR   Data Set Ready
DCD   Carrier Detect        1 <--|
RI   Ring Indicator        9 (not needed)


PC DB9                                  DB9
                                |--> 6     DSR   Data Set Ready
DCD   Carrier Detect        1 <--|
RI   Ring Indicator         9 (not used)



Overcoming length limitations




Hardware Flow Control cables


Cable tips


A kludge using twisted-pair cable


Cable grounding


12.4 Modem Connection


Dialing out from a terminal



Terminal gets dialed into



12.5 Telnet and ssh







12.6 Terminal Server Connection

What is a terminal server ?






Evolution of the "terminal server"






12.7 Connector and Adapter Types



Sex of connector/adapters


Types of adapters


DB connectors


RJ modular connectors


6-conductors: RJ11/14, RJ12, and MMJ




       Plug                         Jack (or socket)
  (Looking at the end           (Looking at the cavity
   end of a cable)               in a wall or PC back)
     .________.                       .________.
     | 654321 |                       | 123456 |
     |__.  .__|                       |__.  .__|
        |__|                             |__|





  DEC MMJ                            Linux PC DB9
Pin  Signal                           Signal  Pin
                                 |---> CTS     8
                                  |--> DTR     4
                                  |--> CD      1
                       (no connection) RI      9

8-conductors and 10-conductors


  Plug                          Jack (or socket)
  (Looking at the end           (Looking at the cavity
   end of a cable)               in a wall)
     .__________.                   .__________.
     | 87654321 |                   | 12345678 |
     |__.    .__|                   |__.    .__|
        |____|                         |____|

12.8 Making or Modifying a Cable

Buy or make ?




Pin numbers of 9 and 25 pin connectors


  ___________                    ________________________________________

Installing DB connectors on cable ends








Installing RJ connectors






Next Previous Contents Text-Terminal-HOWTO-13.html0000644000160500001440000003340512117203375014576 0ustar gfergusers Text-Terminal-HOWTO: Set-Up (Configure) in General Next Previous Contents

13. Set-Up (Configure) in General

13.1 Intro to Set-Up

Configuring (Set-Up) involves both storing a configuration in the non-volatile memory of the terminal, and putting commands in start-up files (on your hard disk) that will run each time the computer is powered on (or possibly only when the run-level changes). This section gives an overview of configuring and covers the configuring of the essential communication options for both the terminal and the computer. The next two major sections cover in detail the configuration of the terminal (see Terminal Set-Up and the computer (see Computer Set-Up (Configure) Details.

13.2 Terminal Set-Up (Configure) Overview

When a terminal is installed it's necessary to configure the physical terminal by saving (in its non-volatile memory which is not lost when the terminal is powered off) the characteristics it will have when it is powered on. You might be lucky and have a terminal that has already been set-up correctly for your installation so that little or no terminal configuration is required.

There are two basic ways of configuring a terminal. One is to sit at the terminal and go thru a series of set-up menus. Another is to send escape sequences to it from the host computer. Before you can send anything to the terminal (such as the above escape sequences), its Communication Interface options such as the baud rate must be set up to match those of the computer. This can only be done by sitting at the terminal since the communications must be set up right before the computer and the terminal can "talk" to each other. See Terminal Set-Up.

13.3 Computer Set-Up (Configure) Overview

Besides possibly sending escape sequences from the computer to configure the terminal, there is the configuring of the computer itself to handle the terminal. If you're lucky, all you need to do is to put a "getty" command in the /etc/inittab file so that a "login:" prompt will be sent to the terminal when the computer starts up. See the section Getty (used in /etc/inittab) for details.

The computer communicates with the terminal using the serial device driver software (part of the kernel). The serial device driver has a default configuration and is also partly (sometimes fully) configured by the getty program before running "login" at each terminal. However, additional configuration is sometimes needed using programs named "stty" and "setserial". These programs (if needed) must be run each time the computer starts up since this configuration is lost each time the computer powers down. See Computer Set-Up (Configure) Details.

13.4 Many Options

There are a great many configuration options for you to choose from. The communication options must be set right or the terminal will not work at all. Other options may be set wrong, but will cause no problem since the features they set may not be used. For example, if you don't have a printer connected to the terminal it makes no difference how the printer configuration parameters are set inside the terminal. This last statement is not 100% correct. Suppose that you have no printer but the computer (by mistake) sends the terminal a command to redirect all characters (data) from the computer to the printer only. Then nothing will display on the screen and your terminal will be dead. Some terminals have a configuration option to inform the terminal that no printer is attached. In this case the terminal will ignore any command to redirect output to the "printer" and the above problem will never happen. However, this doesn't help much since there are many other erroneous commands that can be sent to your terminal that will really foul things up. This is likely to happen if you send the terminal a binary file by accident.

In some cases a wrong setting will not cause any problem until you happen to run a rare application program that expects the terminal to be set a certain way. Other options govern only the appearance of the display and the terminal will work fine if they are set wrong but may not be as pleasant to look at.

Some options concern only the terminal and do not need to be set at the computer. For example: Do you want black letters on a light background? This is easier on the eyes than a black background. Should a key repeat when held down? Should the screen wrap when a line runs off the right end of the screen? Should keys click?

13.5 Communication Interface Options

Some of these communication settings (options) are for both the terminal and the computer and they must be set exactly the same for both: speed, parity, bits/character, and flow control. Other communication options are only set at the terminal (and only a couple of these are essential to establish communications). Still others such as the address and interrupt (IRQ) of the physical port ttyS2 are set only at the computer using the "setserial" command. Until all of the above essential options are compatibly set up there can be no satisfactory serial communication (and likely no communication at all) between the terminal and the computer. For the terminal, one must set these options manually by menus at each terminal (or by using some sort of special cartridge at each terminal). The host computer is configured by running commands each time the computer is powered up (or when people log in). Sometimes the getty program (found in the /etc/inittab file) which starts the login process will take care of this for the computer. See Getty (used in /etc/inittab)

The settings for both the computer and the terminal are:

Some essential settings for the terminal alone are:

If the Getty (used in /etc/inittab) program can't set up the computer side the way you want, then you may need to use one (or both) of the Stty & Setserial commands.


These must be set the same on both the terminal and the computer. The speed is the bits/sec (bps or baud rate). Use the highest speed that works without errors. Enabling flow control may make higher speeds possible. There may be two speeds to set at the terminal: Transmit and Receive, sometimes abbreviated T and R. Usually they are both set the same since stty in Linux doesn't seem to have the option yet of setting them differently. (There is an option to do this with the "stty" command but it seems to actually set them both the same.) Common speeds are 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, ... The slower speeds (like 600) are for printers and hard-copy terminals.

Parity & should you use it ?

For a definition see Parity Explained. Parity-disabled is often the default. To enable parity, you must both enable it and then select either even or odd parity. It probably makes no difference if it's odd or even. For terminals there are sometimes settings for both transmit and receive parity. You should set both of these the same since stty at the computer doesn't permit setting them differently. The PC serial port usually can't support different parities either. Some terminal are unable to set receive parity and will simply always ignore received parity bits. On some older terminals if you use 8-data-bits per byte then parity will not work since there is no room in the hardware for the extra parity bit.

Should you use parity at all? Parity, while not really necessary, is nice to have. If you don't have parity, then you may get an incorrect letter here and there and wind up trying to correct spelling errors that don't really exist. However parity comes at a cost. First, it's more complicated to set up since the default is usually no parity. Secondly, parity will slow down the speed with which bytes travel over the serial cable since there will be one more bit per byte. This may or may not slow down the effective speed.

For example, a hard-copy terminal is usually limited by the mechanics of the printing process. Increasing the bytes/sec when the computer (its UART chip) is transmitting only results in more flow-control "halt" signals to allow the mechanical printing to catch up. Due to more flow-control waits the effective speed is no better without parity than with it. The situation is similar for some terminals: After you implement parity there may be fewer flow-control waits per unit time resulting in more bits/sec (average). However, due to the added parity bits the bytes/sec (average) stays the same.

One option is to install terminals with no parity. Then if parity errors are noticed, it can be implemented later. To spot possible errors with no parity, look for any spelling errors you don't think you made. If you spot such an error, refresh the screen (retransmit from the computer). If the error goes away, then it's likely a parity error. If too many such errors happen (such as more than one every few hundred screens) then corrective action is needed such as: Enable parity and/or reduce speed, and/or use a shorter/better cable. Enabling parity will not reduce the number of errors but it will tell you when an error has happened.

Just the opposite policy is to initially enable parity. Then if no parity errors (error symbols on the CRT) are ever seen (over a reasonable period of time, say a month or two) it may be safely disabled.


This is the character size (the number of data bits per character excluding any parity bit). To use international character sets you need 8 bits. But it's not of much use unless your terminal has the fonts for them. See Character-Sets If you are only going to use ASCII characters, then select 7-bits since it's faster to transmit 7 bits than 8. Some very old terminals only support 7-bit characters.

Which Flow Control (Handshaking) ?

The choice is between "hardware" (for example dtr/cts) or "software" (Xon/Xoff) flow control. While hardware flow control may be faster (if the one or two extra wires for it are available in the cable and if the terminal supports it) in most cases Xon/Xoff should work OK. Some people report that they solved disturbing problems (see below) by converting to hardware flow control but software flow control has worked fine at other installations (and for me personally).

If you use software (Xon/Xoff) flow control and have users who don't know about it, then they may accidentally send an Xoff to the host and lock up their terminal. While it's locked, they may type frantically in a vain attempt to unlock it. Then when Xon is finally sent to restore communication, all that was typed in haste gets executed, perhaps with unexpected results. They can't do this with hardware flow control. See Flow Control for an explanation of flow control.

Port select

Since most terminals have two or more connectors on the back, it is usually possible to assign one of these connecters to connect to the host computer and assign another connector to be the printer port. The connector may have a name next to it (inspect it) and this name (such as Aux, Serial 2, or Modem) may be assigned to either be the main host connection or the printer connection (or the like).

13.6 Quick Attempt

While all the above may seem overly complex, to get a terminal working is often fairly simple. The Quick Install section describes a simple way to try to do this. But if that doesn't work or if you want to make the display look better and perform better, more reading will be needed.

Next Previous Contents Text-Terminal-HOWTO-14.html0000644000160500001440000007732712117203376014613 0ustar gfergusers Text-Terminal-HOWTO: Terminal Set-Up (Configure) Details Next Previous Contents

14. Terminal Set-Up (Configure) Details

Except for the next subsection on sending escape sequences to the terminal, this section mainly presents the details of setting up the terminal manually by sitting at the terminal and going thru menus. If you haven't already done so, you should read Terminal Set-Up (Configure) Overview. It's best if you have a terminal manual, but even it you don't there is information here on many of the options which you might possibly need to set.

The communication parameters such as its baud rate must always be set up at the terminal since if this is not done there can be no communication with the terminal. Once communication is established you have two choices for doing the rest of the terminal configuration. You may continue to configure manually at the terminal and save the results in the terminal's non-volatile memory or you may do this by sending escape sequences to the terminal from the computer each time the terminal is powered on (or the like).

If you know how to set up and save a good configuration inside the terminal it may be the best way. If you don't, you might want to just send the init string from terminfo to your terminal each time you use the terminal. Perhaps doing nothing will still give you a usable terminal. You (or an application program) can always change things by sending certain escape sequences to the terminal.

14.1 Send Escape Sequences to the Terminal

Once the communication interface is established, the rest of the configuration of the terminals may sometimes be done by sending escape sequences to the terminals from the computer. If you have a large number of terminals, it may be worthwhile to write (or locate) a shell script to automatically do this. There may (or may not) be a command you can send to a terminal to tell it to save its current set-up in its non-volatile memory so that it will be present the next time the terminal is powered on.

There is an simple way to send these escape sequences and a complex way. Using the simple way, you never look up escape sequences but issue commands that automatically find an appropriate escape sequence in the terminfo database and send that. Unfortunately, not all the escape sequences which you might want to send are always in the terminfo database. Thus the more complex (but possibly better) way is to directly send escape sequences.

For this complex method you'll need an advanced manual. Old terminal manuals once included a detailed list of escape sequences but newer ones usually don't. To find them you may need to purchase another manual called the "programmers manual" (or the like) which is not supplied with the terminal. A Esc Sequence List for some terminals is on the Internet but it's terse and likely incomplete.

Even without a manual or the like, you may still send commands to configure the terminal by using the programs "tput" and "setterm". See Changing the Terminal Settings. You could just send the terminal an init string from the terminfo entry if the init string sets up the terminal the way want it. See Init String. Unless you plan to have these sequences sent from the computer to the terminal each time the terminal is powered on, you must somehow save the settings in the non-volatile memory of the terminal.

14.2 Older Terminals Set-Up

On older terminals look at the keyboard for labels just above the top row of numeric keys. If they exist, these labels may be what these keys do in set-up mode. Some older terminals may have only one "set-up" menu. Still older ones have physical switches. In some cases not all the switches are well labeled but they may be well concealed. Of course, if you set something with a switch, it's "saved" and there is no need to save the setting in non-volatile memory.

14.3 Getting Into Set-Up (Configuration) Mode

To select options (configure) at the terminal, you must first enter "set-up" mode and then select options (i.e. configure) using menus stored inside the terminal and displayed on the screen. To do this, the terminal does not even need to be connected to a computer. How to get into set-up mode is covered in the terminal's manual, but here's some hints that may help:

If there's a "set-up" key try pressing it. Also try it shifted.

To move around in the set-up menus, try the arrow keys. Use Return, Space, or a special key ("toggle" on old terminals) to select. To exit set-up mode select exit from a menu (or on some older terminals press the set-up key again).

14.4 Communication Options

For the terminal to work at all, speed, parity, :its/character, and communication mode must be set correctly. Incorrect flow control may cause loss and/or corruption of data seen on the screen. The essential communication options were dealt with (for both the terminal and computer) in another section: See Communication Interface. The following list provides some links to that section, as well as some additional communication options set only at the terminal.

14.5 Saving the Set-up

Your set-up must be saved in the non-volatile memory of the terminal so that it will be effective the next time you turn on the terminal. If you fail to save it, then the new settings will be lost when you turn off the terminal. Before you go to the trouble of setting up a terminal, make sure that you know how to save the settings. For modern terminals the save command is done via a menu. In some older terminals, only the manual tells how to save. For many of these you press Ctrl-S to save.

14.6 Set-Up Options/Parameters

What follows in this section describes some of the options which are available in the set-up menus of many terminals. Options are also called parameters or features. Many options may be called "modes". Setting options is often called "configuring". Many of these options may also be set by sending certain escape sequences to the terminal. Different models and brands of terminals have various options and the same option may be called by different names (not all of which are given here) Terse names used by Wyse are enclosed in {...}. Names used mostly for VT terminals are enclosed in {{...}}.

14.7 Emulation {Personality} {{Terminal Modes}}

Most modern terminals can emulate several other terminals. The terminal can likely do more if it is set to emulate itself (actually no emulation) {native personality}. Sometimes there are 2 different emulations for the same model of terminal. For example VT220-7 emulates a VT220 with 7-bits/byte while VT220-8 emulates a VT220 with 8-bits/byte (256 possible characters).

Older models of terminals usually have fewer features than newer models. Suppose one wanted to emulate an old terminal but also wanted some of the advanced capabilities of the later model terminal they are sitting at. This is sometimes possible (to some degree). This feature is sometimes called {Enhance} (or Enhanced ??).

14.8 Display Options

Character Cell Size {Char Cell}

This is the size of the cell in which a character fits. It is measured in pixels (=tiny dots). The more dots, the better the resolution. 10x16 is 10 dots wide by 16 dots high (16 rows and 10 columns). Note the notation is inverted as compared to the notation for matrix dimensions which gives rows (height) first.. Also, the character cell includes rows and columns of pixels allocated for the space between adjacent characters so the cell size which defines the boundaries of an actual character may be smaller.


Usually 80 columns and 24 or 25 lines. This means that there may be up to 80 characters in a row (line) on the screen. Many terminals have a 132 column option but unless you have a large screen, the tiny characters may be hard to read. {{Set 132 column mode}}. If you set 25 lines, make sure that this is in the terminfo. You should also put "export LINES=25" into /etc/profile and also use: "stty -F /dev/ttySx rows 25". If you don't it might result in a scrolling problem (see Terminal doesn't scroll


The cursor may be set to appear as a rectangle (= block) {Blk}. Other options are underline {Line} or blinking. I prefer non-blinking {Steady} block since it's big enough to find quickly but there is no distractive blinking. If you set it invisible (an option on some terminals) it will disappear but new letters will appear on the screen as you type at the invisible cursor.

Display Attributes (Magic Cookies)

Display Attributes may either be magic cookies or be attribute bytes assigned to each character. For magic cookies, there is a limit to their extent: Are they in effect to the end of the line or to the end of the page? It's best to use attribute bytes (which could actually be half-bytes = nibbles).

Display Control Characters {Monitor}

May be called various names such as "Display Controls". When off (normal) it's "Interpret Controls". When set on, you see the escape sequences from the host (which you normally never see on the screen). So that these sequences may be viewed in sequence on a line, they are not acted upon (interpreted) by the terminal. Except that a CR LF sequence creates a new line. See Control Codes.

Double Width/Height

Some terminals can have their characters double width and/or double height. This feature is seldom needed. When changing a line to double width (DW) the right half (RH) is pushed off the screen and there is the question of whether or not to delete (erase) it. "Preserve" means to keep the RH of DW lines. When in double height mode, it may be necessary to send each such line twice (the 2nd time down one row) in order to get a double-height line on the screen.

Reverse Video {Display} (Background Light/Dark)

Normal video is light (white, green, amber) letters (foreground) on a dark (black) background. Reverse video {Display Light} is the opposite: black text on a light background. This is easier on the eyes (unless the room is dark).

Status Line

A status line is a line at the top or bottom of the screen that displays info about the application program you are running. It's often highlighted in some way. With a status line enabled, an application can send the terminal a special escape sequence which means that the text that follows is for the status line. However, many applications don't use this feature but instead only simulate a real status line by direct cursor positioning. The ordinary user looking at it doesn't know the difference.

Upon 80/132 Change: Clear or Preserve?

When switching the number of columns from 80 to 132 (or conversely) should the data displayed in the old format be erased (cleared) or preserved? {80/132 Clr} {{Screen Width Change}}. It should make no difference how you set this option since if an application program uses 132 columns, it should set this option appropriately via a control sequence.

14.9 Page Related Options

For a Wyse terminal to be able to access multiple pages of display memory {Multipage} must be set to on.

Page Size

The terminal memory may be divided up into a number of pages. See Pages and Pages (definition) for explanations of pages. You may partition the page memory into a number of pages of selected length. Linux applications don't seem to use pages at present so it shouldn't make much difference how you set this up.

Coupling (of cursor & display)

The terminal memory may be divided up into a number of pages. See Pages and Pages for explanations of pages. When the cursor is moved to a location in video memory not currently displayed (such as another page, or on the same page but to a location not displayed on the screen) should the display change to let one view the new cursor location? If so, this is called "Coupling". For cursor movement within the same page there is "Vertical Coupling" and "Horizontal Coupling". For movement to another page there is "Page Coupling".

14.10 Reporting and Answerback

The terminal will identify itself and its state, or send out a pre-recorded message in response to certain escape sequences.

Answerback Message (String)

You may write a short message during set-up which may optionally be sent to the host at power-up or be sent to the host in response to a request from the host (perhaps the ENQ (inquire) control character).

Auto Answerback

If set, sends the answerback message to the host at power-on without the host asking for it. Do any "getty" processes look for this ??

Answerback Concealed

If set, will never let anyone see the answerback message (except of course the host computer). If it needs to be changed, deselect "answerback concealed" and the formerly concealed message will be destroyed so you then may enter a new message (but you don't get to see the old one).

Terminal ID {ANSI ID}

The terminal sends this reply in answer to a request for identity.

14.11 Keyboard Options


When set, pressing any key makes a click (broadcast by a tiny loudspeaker in the keyboard). These clicks annoy some people and I think it's best to set keyclick off.

Caps Lock {Keylock}

When the Caps-Lock key is down, should only the alphabetic keys generate shifted characters? If set to {Caps} or upper-case-only then hitting a number key with the Caps-Lock on will type the number. To get the symbol above the number one must manually hold down the shift key. This is the normal mode. If set to {Shift} then all keys type the shifted character when Caps-Lock is on (hitting the 5 key should type % without holding down Shift, etc.).

Auto Repeat {Repeat}

If a key is held down then that key is repeatedly "typed". This is handy for repeatedly typing the same character to create a line across the page.

Margin Bell

When the cursor is 8 columns away from the right side of the display, a bell is rung (like on an old typewriter). Almost all editors will automatically create a new line if needed (no need to hit the Return key) so this feature is seldom needed.

Remapping the Keys

The code sent to the host when a key is pressed is normally the ASCII code for that key (depends also on Shift and Control key). On some terminals you may make any key send any code you wish. That is, you may completely remap the keyboard by setting up the terminal that way. This may be useful for some foreign languages and Dvorak keyboard layouts, etc. which permit one to type faster. Even for terminals that don't have the feature, there is software to remap the keyboard (and screen also). It's something like a device driver which uses a pseudo terminal. See Character Mapping: mapchan

Corner Key (for Wyse only)

Wyse terminals have a key near the lower left corner which may be set to do various things. Its may be labelled "Funct", "Compose Character", "Alt", "Hold" or "Scroll Lock". Early models don't have all of the following options:

Numeric Keypad or Arrow Keys Sends

The numeric keypad (the rectangle of mostly numeric keys to the right of the main part of the keyboard) can be set to send special codes which will do special things in certain application programs. Ditto for the arrow keys. There is thus a "normal" mode where they send what is shown on the keycap (or the normal code sequence for an arrow-key) and an "application" mode where special escape sequences are sent. In some cases there is a "hex" numeric mode which is almost like normal numeric mode except that 6 non-numeric keys send the letters A-F. Thus one may type for example "B36F" on the numeric keypad.

What does shifted-del and shifted-bs send?

Depending on how they're set up, shifted-del sometimes sends the control character CAN and shifted backspace sometimes sends DEL.

PC Scan Codes

Many terminals can emulate a PC keyboard by sending PC scancodes (see Keyboard-and-Console-HOWTO) instead of ASCII codes. This is mostly used with special Multiuser DOS OSs. It won't work with ordinary MS DOS. See Non-Linux OSs However, hardly any Linux programs that run via the serial port can accept scancodes. If this is the latest version of this HOWTO, let me know if any programs do this. I think Foxpro can do it. You need to define smsc and rmsc in the terminfo, and perhaps pctrm.

When using scancodes it's best to use hardware flow control since normal software flow control conflicts with some of the codes (??). If you do use software flow control, you must use the XPC type of flow control. It uses 0x65 and 0x67 for on and off characters. It must be set this way both in the terminal and by stty for the PC.

Alternate Characters

Some keys may have alternative letters on them. When keys is set to "Typewriter" they send what they would normally send on a typewriter. When keys is set to something else the alternative characters are sent.

14.12 Meaning of Received Control Codes

Auto New Line {Newline}

In this case "New Line" means a new line starting at the left margin below the current line. In Linux and C "new line" (NL) may have a different meaning: the line-feed control character LF also called new-line or NL. This is because in Linux text files, the LF character means a "new line starts here" so it's labeled NL. Normally, a LF (NL) sent to a terminal only results in the cursor jumping down one line below where is was and does not move the cursor back to the start of this "new line".

If Auto New Line is set, the above "normal" situation is canceled and a physical new line is created on the display upon receiving a LF from the host. This is exactly what one wants in Linux. Except that (when Auto New Line is set) the Return (or Enter) key sends a CR LF sequence to the host (for Wyse and VT100, but for VT420 ??). Since Linux uses LF as a "new line" marker in files, Linux would like only a LF to be sent (and not a CR LF). Thus the "New Line" option is seldom used. Instead, the required translations are made by the serial port device driver by default. It is as if one gave the command "stty onlcr icrnl". But you don't need to do this since it's the default.

Auto Line Feed {Rcv CR}

This is just another type of "Auto New Line". When a CR (carriage return) character is received, a LF (line feed) action is added resulting in a new line being displayed. Since Linux marks the end of lines with LF, this option is not used.

Recognize Del (Wyse Only ??) or Null

If off, the DEL character received by the terminal is ignored. If on the DEL performs a destructive backspace. Null characters are usually ignored in any case. Both DEL and NULL are sometimes used for padding. See Padding

14.13 Where New Text Goes

Line Wrap

Also called "Auto Wrap(around)". What happens when the right edge of the screen is reached (col. 80, etc) and no return character (or the like) has been sent from the host? If Line Wrap is set, then the rest of the line displays on the line below, etc. Otherwise, the rest of the line is lost and is not seen on the screen. Any good application should handle the situation correctly (provided the terminfo knows how Line Wrap is set). Thus even if Line Wrap is not set, the application should either wrap the screen for long lines or provide another way for you to view the cutoff tail of long lines (by use of the arrow keys, etc). But a raw copy command (and other situations) may not do this so it's often best to set line wrap.

For an 80 col. screen, most terminals only wrap if the 81st character from the host is a graphic (printable) character. This allows for the case where 81st character from the host might be "return" or a "newline" (non-graphic characters) which means that the application is handing the wrapping OK and intervention by the terminal is not needed.


Scrolling {Scrl} is where all the lines on the screen move up or down. Its also called "panning" which includes movement sideways. In ordinary scrolling lines roll off the bottom or top of the screen and disappear, and new lines from the host appear at the opposite edge (top or bottom). There are 3 types of this: smooth, jump, or burst. Burst is not really scrolling since its an instant replacement of an old screenfull by a new one (although some lines on the new screen may be from the old screen). Jump is where new lines jump into view one at a time. Smooth {Smth} is where the text moves at a steady speed upward or downward. If the smooth scroll rate is slow enough, one may read the newly visible lines when they are still scrolling (in motion).

Smooth scrolling on slow terminals was once useful since one could continue reading as the display was scrolling. But with higher baud rates, jump scroll is so fast that little time is lost as the new display appears. Since it takes a little longer to read scrolling text than fixed text, it may actually waste more time if smooth scrolling is selected.

If (auto)scrolling {Autoscrl} is disabled, then new text from the host must go somewhere so it is put at the top of the display. If the old text is not erased, the new text merges (nonsensically) into the old. If the old text is erased, then the new text is out of context. So keep (auto)scrolling enabled.

New Page?

See Pages and Pages for explanations of pages. When the current page is full (the last line is finished) should the page scroll, or should a new page be created (leaving the previous page stored in the terminal's display memory). If {Autopage} is set, then a new page is created. Since you are probably not using pages, you should probably set this to off.

14.14 Function Keys

These are the keys labeled F1, F2, etc. On older terminals they may be labeled PF1, PF2, etc. where the P stands for Programmable. Some keyboards have both. One may program (redefine) these keys to send out a string of user-defined bytes. This doesn't work for older terminals such as vt100 or for the Linux command-line interface (how sad). They may often be easily "programmed" using a certain set-up menu {FKey}. On some terminals, one may also specify where this string is sent to when the key is pressed. In "normal" mode, pressing the key is just like typing the string at the keyboard. In "local" mode pressing the key sends it to the terminal (just like if the terminal was in local mode). This may be used to send escape sequences to the terminal so as to configure it in a special way. In "remote" mode, the string is always sent out the serial port to the host computer (even if the terminal is in local mode).

14.15 Block Mode Options

Some options are only for the case of Block Mode. This option is powerful since it provides forms and takes load off the host computer by transmitting in bursts. But it's more complicated to set up and is thus not used too much.

Forms Display

In block mode some regions of the screen are for the text of forms and are thus write-protected "Prot" {WPRT}. Options may set the characters in these regions to appear dim, reverse video {WPRT Rev}, and/or underlined {WPRT Undrln}. {WPRT Intensity} may be set to dim, normal, or even blank (invisible)

Send Entire Block ?

Should write-protected text (the original text in the form) be sent to the host upon transmission of a block: {Send All} or is write-protected text also read-protected: {Send Erasable}

Region to Send

Should the entire screen be sent or just the scrolling region? {Send Area}. Should the sending stop when the current cursor position is reached? If {Xfer Term} is set to Cursor, only the data on the screen up to the cursor is sent.

Block/Page terminator

What is the termination symbol to be appended to a block of data? {Blk End} or at the end of a page {Send Term}ination.

14.16 Locks

There are various types of Locks. One is the Locked keyboard due to flow control. See Keyboard Lock Another lock {Feature Lock} is that which prohibits the host computer from changing the terminal set-up by sending certain escape sequences to the terminal. Placing such a lock may result in unexpected behavior as application programs send escape sequences to the terminals that are ignored. Not all set-up parameters lock. Unless you have a good reason to do so, you should not enable such locking.

A Function Key lock will prohibit the computer from redefining what a programmable function key sends. You may want to use this if you have something important programmed into the function keys.

14.17 Screen Saver {Scrn Saver}

Also called "CRT Saver". This turns off (or dims) the screen after the terminal is not used for a period of time. It may prolong the life of the screen and save some energy. Hitting any key will usually restore the screen and may "execute" that key so it's best to hit the shift-key, etc.

14.18 Printer

For Wyse, if there is no {Printer Attached} set it to Off. It's not essential to do this, but if you do it any escape sequence to send text to the printer (instead of the terminal) will be ignored.

Setting up the printer port is about the same (usually simpler) as setting up the communications on the main port. There are a couple of options specific to the printer. Is the printer a serial or parallel printer? If it's parallel it should be designated as such in setup and connected to the parallel port on the terminal (if there is one). Should a FF (form feed) be sent to the printer at the end of a print job? If {Print Term} is set to FF, this will happen.

Next Previous Contents Text-Terminal-HOWTO-15.html0000644000160500001440000017677012117203376014616 0ustar gfergusers Text-Terminal-HOWTO: Computer Set-Up (Configure) Details Next Previous Contents

15. Computer Set-Up (Configure) Details


15.1 Getty (used in /etc/inittab)

Introduction to Getty


The arguments which are permitted depend on which getty you use:
Two gettys best for directly connected terminals are:

  1. mingetty
  2. fbgetty
  3. fgetty
  4. rungetty


strings getty | grep getty
getty -h
should show the agetty options [-hiLmw].



Getty exits after login (and can respawn)





If getty run from command line: Programs get stopped



agetty (may be named getty)

An example line in /etc/inittab:


Agetty's auto-detection of parity problems








8-bit data bytes (plus parity)


getty (part of getty_ps)


# 38400 bps Dumb Terminal entry

# 19200 bps Dumb Terminal entry

# 9600 bps Dumb Terminal entry



@L    The serial line to which getty is attached.
@S    The system name.
      that have a non-null ut_name field.


linux# getty -c /etc/gettydefs



Restart init:
linux# init q







15.2 Stty & Setserial


15.3 Setserial


Setserial problems with linmodems, laptops



setserial is a program used for the user to communicate with the serial device driver. You normally never need to use it, provided that you only use the one or two serial ports that come as standard equipment with a PC. Even in other cases, most extra serial ports should be auto-detected by modern kernels. Except you'll need to use setserial if you have an obsolete ISA serial port set by jumpers on the physical hardware or if your kernel (such as 2.2 or older) doesn't both detect and set your add-on PCI serial ports. In some cases the setserial program may have been previously used and the wrong serial port data has been manually given by the some past user (perhaps by you). If setserial hasn't been configured to accept what the kernel says, it will override the (likely correct) kernel data with what someone previously set.

setserial allows you (or a shell script) to talk to the serial software. But there's also another program, tt/stty/, that also deals with the serial port and is used for setting the port speed, etc. setserial is really a misnomer, it doesn't set any information on the serial card. Example: it can't change the irq set on the card. More details on this later







The serial driver (for Linux Kernels 2.4 and 2.6) looks for a few "standard" legacy serial ports, for PnP ports on the ISA bus, and for all supported port hardware on the PCI bus. If it finds your ports correctly, then there's no need to use setserial unless they have been "set" incorrectly in the setserial configuration file. The driver doesn't probe for the IRQs of old ISA serial ports set with jumpers on the card and may get these wrong.


Serial module unload

If a serial module gets unloaded, the changes previously made by setserial will be forgotten by the driver. But while the driver forgets it, a script provided by the distribution may save it in a file somewhere so that it can the restored if the module is reloaded. Also changes made by setserial may be stored in setserial's configuration file (see the documentation for your distribution, this info is not in the man page).

Giving the setserial command




setserial -g /dev/ttyS*


Configuration file








setserial /dev/ttyS2 -v autoconfig



Boot-time Configuration






Edit a script (required prior to version 2.15)






An example line in such a script was:



/sbin/setserial  /dev/ttyS3 auto_irq skip_test autoconfig


Configuration method using /etc/serial.conf, etc.














Laptops: PCMCIA


15.4 Stty


stty does much of the configuration of the serial port but since application programs (and the getty program) often handle this, you may not need to use it much. It's handy if you're having problems or want to see how the port is set up. It also configures the terminal interface which is not only used by the serial port but is also used anytime you use a command-line interface in Linux. Try typing ``stty -a'' at your terminal/console to see how it's now set. Also try typing it without the -a (all) for a short listing which shows how it's set different than "normal" which is how it's set using the command "stty sane". Don't try to learn all the settings unless you want to become a serial historian since many of the settings are only for slow antique dumb terminals of the 1970's. Most of the defaults should work OK.



Whereas setserial only deals with actual serial ports, stty is used for terminals regardless of whether they are accesses via a serial port, network, or by a virtual terminal on Linux PC monitor, or a GUI terminal window such as xterm. For the PC monitor, xterm, or a network many of the stty settings are meaningless. Changing the baud rate, etc. doesn't appear to actually do anything.




Flow control options






Using stty at a "foreign" terminal



Two interface modes at a terminal

When using a shell (such as bash) with command-line-editing enabled there are two different terminal interfaces (or line disciplines: what you see when you type stty -a). When you type in modern shells at the command line you have a temporary "raw" interface (or raw mode) where each character is read by the shell's command-line-editor as you type it. Once you hit the <return> key, the command-line-editor is exited and the terminal interface is changed from raw to the nominal "cooked" interface (cooked mode) for the terminal using the stty configuration that was used for the last cooked mode (the shell has saved it and it gets restored). This cooked mode lasts until the next prompt is sent to the terminal (which is only a small fraction of a second) but it exists during the execution of the command (or at least during the first stage of the command execution). Note that one never gets to type any command into this cooked mode but what was typed in raw mode on the command line starts execution by the shell while in cooked mode.

When a prompt is sent to the terminal, the terminal goes from "cooked" to "raw" mode (just like it does when you start an editor such as vim. The prompt signals starting the command-line editor. The settings for the "raw" mode are based only on the basic stty settings taken from the "cooked" mode. Raw mode keeps these setting but changes several other settings in order to change the mode to "raw". It is not at all based on the settings used in the previous "raw" mode (as contrasted to "cooked" mode which gets restored by the shell to its previous settings). Thus if one uses stty to change settings for the raw mode, such settings will be permanently lost as soon as one hits the <return> key at the terminal.

Now when one types stty to look at the terminal interface, one may either get a view of the cooked mode or the raw mode. You need to figure out which one you're looking at. It you use stty from a foreign terminal (other than the terminal you are currently typing at) then you will likely see the raw mode settings since the terminal is in raw mode almost all the time. Any changes made will only be made to the raw mode and will be lost when someone presses <return> at the foreign terminal you tried to "set". But if you type a stty command to view/change the configuration of the terminal you are using, and then hit <return> it's a different story. The <return> puts the terminal in cooked mode and your changes are saved by the shell before it returns to raw mode. Since going into raw mode doesn't change all stty settings, some of the changes you made via stty may still be present in raw mode and will not get destroyed by <return>.

This situation can create problems. For example, suppose you corrupt your terminal interface so that it's not displaying what you type, etc. To restore it you go to another terminal (on the same PC) and type "stty -F dev/ttyS1 sane" (or the like). It will not work because the terminal is in raw mode! Of course you can try to type "stty sane ..." at the terminal that is corrupted but you can't see what you typed. All the above not only applies to dumb terminals but to virtual terminals used on a PC Monitor as well as to the terminal windows in X. In other words, it applies to almost everyone who uses Linux.


Where to put the stty command ?



Obsolete redirection method






15.5 Terminfo & Termcap (brief)




15.6 Setting TERM and TERMINFO




What is the terminfo name of my terminal ?



15.7 Rarely Needed /etc/ttytype File


15.8 Login Restrictions


15.9 Run Command Only If TERM=my_term_type



Example for ls Function


if [ "$TERM" = linux ]; then
    eval `dircolors`;
elif [ "$TERM" = vt220 ]; then
    declare -xf ls

15.10 Character Mapping: mapchan


Next Previous Contents Text-Terminal-HOWTO-16.html0000644000160500001440000003535712117203376014612 0ustar gfergusers Text-Terminal-HOWTO: Terminfo and Termcap (detailed) Next Previous Contents

16. Terminfo and Termcap (detailed)

16.1 Intro to Terminfo




16.2 Terminfo Database




Where is the database located ?

Compiled database locations




Source-code database locations



Terminfo Compiler (tic)


Look at Your Terminfo


Deleting Data Not Needed


16.3 Bugs in Existing Terminfo Files (and Hardware)




16.4 Modifying Terminfo Files



16.5 Init String



16.6 TERM Variable




16.7 Terminfo/Termcap Documents

Next Previous Contents Text-Terminal-HOWTO-17.html0000644000160500001440000010730312117203376014602 0ustar gfergusers Text-Terminal-HOWTO: Using the Terminal Next Previous Contents

17. Using the Terminal

17.1 Intro to Using the Terminal

This section is about controlling the terminal-computer interface and/or changing the terminal set-up while using the terminal. It explains (or points to explanations of) how the user of a terminal can control and inspect the interface and how to use various commands provided by the device driver. It does not explain how to use the many application programs, shells or most Linux utilities. Two commands commonly used at the terminal are:

17.2 Starting Up the Terminal

Of course the power must be on for the terminal to work. If you don't see a login prompt hit the "return" (or "enter") key a few times. Then type your account name (followed by a return/enter) and your password when prompted for it (also followed by return/enter). Make sure not to type all capital letters. If you do, the computer may think that you have an old terminal that can't send lowercase letters and the serial driver may set itself up to send only capital letters to the terminal.

If nothing happens, make sure that both the host computer and the terminal are OK. If the host computer is shut down (no power) what you type at the terminal keyboard may appear on the screen since the transmit and receive pins at the computer may be connected together resulting in echoing of characters by an "off" computer. If you can't log in when the host computer is running, see Trouble-Shooting.

17.3 Terminal (Serial) Device Driver

When typing at the command line, the shell (such as the Bash shell) is reading what you type and reacting to it. What you type first passes thru the terminal driver part of your operating system. This driver may translate certain characters (such as changing the "return" character generated by the "return" key into a "new-line" character for Linux files). It also recognizes certain control codes which you may type at the keyboard such as ^C to interrupt the execution of a program. It also normally echoes what you type back to the display. Stty may be used to configure how this terminal driver behaves, including disabling some (or all) of its functionality.

17.4 Problems with Editors

There may be some problems with using both emacs and vi on some terminals. A few terminals have no escape key (ESC) so you may need to type Ctrl-[ to get ESC.


If software flow control exists, then the ^S command in emacs will freeze the display. The ^Q command will unfreeze the display. One fix is to map this to another key-press by configuring emacs that way. Some terminals have meta keys although you may need to setup the terminal to create a meta key.

vi and Cursor-Keys

Vi uses the esc-key as a command to exit insert mode. Unfortunately for most terminals the arrow-keys send an an escape sequence (starting with the ESC character) to the host. Vi must distinguish between these two meanings of ESC. A smart vi (such as vim if configured for it) is able to detect the difference by noting the time between the ESC and the next key. If it's a short time, then it's likely that a cursor key was pressed. Use "help cursor-keys" in vim to find out more.

Here's another way to fix this. On VT terminals the left-arrow-key may be either set to send ESC [ D or ESC O D. The other arrow keys are similar but use A, B, and C instead of D. If you're having problems, choose ESC [ D since the "O" in the other alternative could be interpreted by vi as a command to "Open a line". The "[" should be interpreted by vi to mean that an arrow-key has been pressed. ESC [ D will be sent provided "Cursor Key Application Mode" has not been set. ESC [ D is normally the default so everything is seemingly OK. Except that many termcaps contain a string (not the init string) which sets what you want to avoid: "Application Mode". Editors may send this string to the terminal when the editor starts up. Now you are in trouble.

This string has the termcap code "ks" (smkx in terminfo) meaning enable the function (and related) keys (including the arrow keys). An application enables these keys by sending the "ks" string to the terminal. Whoever wrote the termcap reasoned that if an application wants to enable these keys, then they should be put into "Application Key Mode" since this is an "application", but you don't want this.

The Linux console has no "ks" string so you can't fall into this trap at the console. For other terminals you may need to edit the termcap (or terminfo) or use another termcap entry. You need to change not only the "ks" string but also the termcap definitions of what they send: kd, kl, kr, ku. Then run tic to install it.

For vim (vi iMproved) there is a way to set it up to work OK with ESC O D (so you don't need to edit termcap): See vim help for "vt100-cursor-keys". You may run "gitkeys" and then press your cursor keys to see what they send but they may be set to send something different when you're in an editor.

17.5 Problem with Slow Scrolling

The scrolling speed of the text terminal is limited by the speed over the serial line. This limitation is good in one respect since the scrolling speed is slow enough that you can almost read what is scrolling on the screen before it disappears off the bottom of the screen.

But there is a downside to this. For example, if you copy a large number of files (like everything on your hard drive) and use options to display the full name (path name) of each file copied, then the speed limitations of the serial line may only only display 30 files per second on the screen. But your hard drive can copy many times faster than this but the terminal will slow down the transfer to the speed at which it can be displayed by the terminal. It does this by Flow Control.

The fix is to disable "progress" information being displayed on the screen for cases where it slows down the "progress". If it just updates progress numbers a few times per second or less, it shouldn't be a problem.

17.6 Bugs in Bash ?

One problem still outstanding is that if certain terminal keys send bytes with the high order bit set to 1, then Bash seems to ignore the meaning for them as defined in a terminfo entry. This may be because, unless one is using 7-bit ASCII, bytes with the high order bit set to 1, may represent a non-English letter. I reported this as a bug in Bash (but years later realized that it may not have been a bug). Other programs such as the vim editor and the lynx browser work OK with such keys (when they are set to use 7-bit ASCII).

To work around this problem, one may define what these keys should do in Bash by putting such definitions into /etc/inputrc. For example, A Wyse 60 will send D0-D3 when the arrow-keys are hit provided the terminal is in "application key mode". After modifying the terminfo to reflect this, they still wouldn't work on the command line in the Bash shell. So I explicitly defined the arrow-keys in /etc/inputrc like this:

# Arrow keys in 8 bit keypad mode: Sends d0-d3.  -ap means application.
$if term=wy60-25-ap
set enable-keypad on
"\xd0":         backward-char
"\xd1":         forward-char
"\xd2":         next-history
"\xd3":         previous-history

If the terminal is already in "application key mode" there's no need to "set enable-keypad on". enable-keypad will send the terminal the escape sequence named smkx in terminfo (which for wyse60 is \E~3 and makes the arrow keys send D0-D3). Many other applications (other than Bash) send this without needing to be told to do so.

A fixed Bash bug

There have been problems with the readline interface to the Bash shell. Bash 2.01 (1998) had a readline interface which was quite corrupted if one used a dumb terminal. This was fixed in later versions.

17.7 Color ls Corruption

If ls is corrupting your terminal emulation with the color feature, turn it off. ls --color, and ls --colour all use the color feature. Some installations have ls set to use color by default. Check /etc/profile, etc. for ls aliases. See Example for ls Function for how to have ls do color for the console and do monochrome for terminals.

17.8 Display Freezes (hung terminal)

The symptom of a hung terminal is where what you type doesn't display on the terminal (or in some cases displays but doesn't do anything). If what you type is invisible (or does nothing) type ^Q to restart flow (if flow control stopped it). Hanging may also be due to:
Sent terminal binary or Abnormally exited a program
If you didn't do any of these two, then the program you're running could by buggy or you interaction with it fatally illegal.

If you want to quit the program you were running and you can't do it by the usual methods (some programs have special keys you must hit to exit) then try killing it from another terminal using "top" or "kill". If the process refuses to die, then kill it with signal 9 from top (or use "kill" on the command line). The "9" type of forced exit may leave some temporary files lying around as well as a corrupted interface. If this doesn't work, killing the login shell should result in a startup of getty with a new login prompt. If all else fails, you may need to reboot the computer or even power it down. Just rebooting may not alter the possibly corrupted content of the serial port hardware registers.

People new to Linux may unintentionally press Ctrl-S (^S) (or the "No Scroll" key) which mysteriously freezes the screen (although that is what this key is supposed to do if you use software flow-control). To restore normal screen interaction, press Ctrl-Q (^Q). Note that everything typed during the "freeze" gets executed but you don't see any report of this until you hit ^Q. Thus when it's frozen, don't type anything drastic that might destroy files, etc. One argument for using hardware flow-control is to prevent such freezes.

17.9 Corrupted Terminal Interface

This includes the case of a "frozen display" = "hung terminal" of the previous section.

Symptoms and some fixes

When the display doesn't look right, or when what you type doesn't display correctly (if at all), or nothing happens when you type a command, you may have a corrupted terminal interface. In rare cases, when the serial port hardware gets itself corrupted, the only fix may be to cycle power (turn off the PC and reboot). In some cases just cycling power for the terminal will fix it. Sometimes logging in again will solve the problem. To do this, kill the shell process running on the terminal (or kill getty if it's running). You may do this from another terminal. Once killed, a new getty process respawns which hopefully will end the corruption. Recycling power (or resetting) for the terminal may help too.

The corruption may be due to things such as:

If everything was working normally but it suddenly goes bad, it may be that the interface got corrupted by something you did. Three mistakes you might have made to corrupt the interface are:

Sent terminal binary characters

Your terminal will change its characteristics if sent certain escape sequences or control characters. It you inadvertently try to display a binary file, it might by chance contain such sequences which may put your terminal into some strange mode of operation or even make it unusable. Always view or edit a binary file with programs designed for that purpose so that this doesn't happen. Most editors and pagers will handle binary OK so as not to corrupt the interface. Some may display a message telling you that they can't edit binary. But you're likely to corrupt things if you: "cat ...." or "cp .... /dev/tty.." or run a program which sends binary output to "standard output" (unless you redirect such output with >, etc.).

Corruption can also happen when using a communications program where a remote computer may send binary to your screen. There are numerous other ways it can happen so be prepared for it. Even a supposedly text file could contain unwanted control codes.

To fix this problem reset the terminal. Type either just "reset" or "tset" or "setterm -reset" (followed by a <return> of course -- what you type will likely not be readable on the screen). This will send the reset string from the terminfo entry to the terminal. As an alternative to this, if the correct set-up has been saved inside the terminal then pressing a special key(s) (perhaps in setup mode) may restore the settings. Then you might still need to use "reset" to send the init string if you use it to set up your terminal.

Reset command was broken but now fixed

Note that in 2000 the "reset" command appeared to be broken for terminals that needed "clocal" set since "reset" seemed to unset "clocal". In 2001 it appears to be fixed so you may not need to read the rest of this paragraph. If you have this problem, using "reset" will only make the situation worse by disabling communication between the terminal and computer. You will likely need to log in again and hope the getty sets "clocal". If you see a login prompt without asking for it, you're in luck. Otherwise see Symptoms and some fixes for how to get a login prompt. You should try out "reset" before you need it and use "setterm -reset" if "reset" logs you out or otherwise doesn't work right. I submitted a bug report in Mar. 2000 but never got a "fixed" notice.

Character corruption

For the case where you see strange "graphic" characters instead of the normal ones, pressing ^O may switch back to the normal letters. The "reset" command also does this but it resets everything else too.

There's the case where all letters have the wrong attribute (too dim, bright, blinking, or even invisible :-) but the whitespace created by tab characters is normal. This was caused by an escape sequence which set this attribute but the attribute doesn't apply to the whitespace created by tab characters. Fix by resetting, etc.

Abnormally exited a program

Large application programs (such as editors) often use the stty command (or the like) in their code to temporarily change the stty configuration when you are running the program. This may put the device driver into "raw" mode so that every character you type goes directly thru to the application program. Echoing by the driver is disabled so that everything you see on the screen comes directly from the application program. Thus many control commands (such as ^C) may not work within such applications.

When you tell such an application to quit, the application program first restores the stty settings to what they were before the application program started. If you abnormally exit the program then you may still be in "raw mode" on the command line. You should suspect this has happened when what you type no longer displays on the screen.

To get out of raw mode and restore the normal stty settings type "stty sane". However, you must type this just after a "return" and end it with a "return". But hitting the "return" key doesn't do the job since the "return" code no longer gets translated to the new-line characters that the shell is waiting for. So just type new-line (^J) instead of "return". The "sane" terminal interface may not be exactly the same as the normal one but it usually works. "stty sane" may also be useful to get out of a corrupted interface due to other causes.

17.10 Special (Control) Characters

A number of control characters which you may type at the keyboard are "caught" by the terminal driver and perform various tasks. To see these control commands type: stty -a and look at lines 2-4. They are tersely explained in the stty manual pages. They may be changed to different control characters or disabled using the stty command. Thus your control characters might be different than those described below. They are used for command-line editing, interrupting, scrolling, and to pass the next character thru transparently.

Command-Line Editing

While the terminal driver has a few commands for command-line editing, some shells have a built-in real editor (such as "readline" in the Bash shell). Such an editor is normally on by default so you don't need to do anything to enable it. If it's available you don't need to learn many of the following commands although they often still work along with the command-line editor. The most important to learn are ^C (interrupt), ^D, and how to stop scrolling.

Interrupting (& Quit, Suspend, EOF, Flush)

Stop/Start Scrolling

If what you want to see scrolls off the bottom of the screen, you may prevent this by sending a "stop" signal (^S or Xoff) to the host (provided Xon-Xoff Flow Control is enabled). Send a "start signal to resume (^Q or Xon). Some terminals have a "No Scroll" key which will alternately send Xoff and Xon or possibly send the hardware flow control signals ?? Here's what ctrl-S (^S) and ctrl-Q (^Q) do:

If you want to both stop scrolling and quit, use ^C. If you want to stop scrolling to do something else but want to keep the program that was generating the output in memory so you can resume scrolling later, use ^Z suspend.

An alternative scrolling method is to pipe the output thru a pager such as more, less, or most. However, the output might not be standard output but could be error output which the pager doesn't recognize. To fix this you may need to use redirection "2>&1" to get the pager to work OK. It is often simpler to just use ^S and ^Q unless you need to scroll backwards.

At a PC console (emulating a terminal) you may scroll backwards by using Shift-PageUp. This is frequently needed since the scrolling is often too fast to stop using ^S. Once you've scrolled backwards Shift-PageDown will scroll forward again.

Take next character literally

^V sends the next character typed (usually a control character) directly thru the device driver with no action or interpretation. Echoed back are two ASCII characters such as ^C.

17.11 Viewing Latin1 Files on a non-Latin1 terminal

Some "text" files are 8-bit Latin1 (=ISO-8859-1). See Character-Sets. If you have a terminal that will not display Latin1 (or don't have the Latin1 character set installed), then certain symbols (such as a bullet) will display wrong. When viewing manual pages (they are Latin1) you may give the option -7 to man so as to translate everything to ASCII. Are there some pagers that make these translations ??

17.12 Eliminating Overstriking in Files

If one uses the "man" command to view a manual page but instead redirects the output to a file, that file will have overstrikes in it. Overstrikes are where some printed characters appear bold by printing them twice in the same location. Thus to print an overstrike character the file contains a backspace after the character and then the same character repeated. If this is in a file, it's fine if you are going to print it on a printer (unless the normal output from the printer is so darks that overstriking makes little improvement). But it's not so good if you want to use the file to email or edit.

One way to get rid of the overstrikes is to use the "ul" (underline) command. You type: ul -t dumb my_overstruck_file > output_file The ul command converts overstrikes to bold for whatever terminal is specified and adds escape sequences to the output_file to generate the bold. But the terminal of type "dumb" has no escape sequences so you get the desired result. There are other ways to do this but this is a possible use for a terminal of type "dumb".

17.13 Inspecting the Interface

These utility programs will provide information about the terminal interface:

17.14 Changing the Terminal Settings

The terminal settings are normally set once when the terminal is installed using the setup procedures in the terminal manual. However, some settings may be changed when the terminal is in use. You normally would not give any "stty" or "setserial" commands when the terminal is in use as they are likely to corrupt the terminal interface. However, there are changes you may make to the appearance of the terminal screen or to its behavior without destroying the integrity of the interface. Sometimes these changes are made automatically by application programs so you may not need to deal with them.

One direct method of making such changes is to use the setup key (or the like) at the terminal and then use menus (or the like) to make the changes. To do this you may need to be familiar with the terminal. The other 3 methods send an escape sequence from the computer to the terminal to make the changes. These 3 examples show different methods of doing this to set reverse video:

  1. setterm -reverse
  2. tput -rev
  3. echo ^[[7m


This is the easiest command to use. It uses long options (but doesn't use the normal -- before them). It consults the terminfo database to determine what code to send. You may change the color, brightness, linewrap, keyboard repeat, cursor appearance, etc.


The "tput" command is similar to "setterm" but instead of using ordinary words as arguments, you must use the abbreviations used by terminfo. Many of the abbreviations are quite terse and hard to remember.


In the example "echo ^[[7m" to set reverse video, the ^[ is the escape character. To type it type ^V^[ (or ^V followed by the escape key). To use this "echo" method you must find out what code to use from a terminal manual or from terminfo or termcap. It's simpler to use setterm or tput if you are typing on the command line. Since "echo ..." will execute faster (since it doesn't do any lookups) it's good for using in shell scripts which run at start-up, etc.

Saving changes

When you turn off the terminal the changes you made will be lost (unless you saved them in non-volatile terminal memory by going into set-up mode and saving it). If you want to use them again without having to retype them, put the commands in a shell script or make it a shell function. Then run it when you want to make the changes. One way to make the changes semi-permanent is to put the commands in a file that runs each time you login or start up the computer.

17.15 Multiple Sessions

The "screen" package runs multiple sessions something like virtual terminals on the console: See The Console: /dev/tty?. You can switch back and forth between the sessions. The non-free Facet Term software also does this. See FacetTerm

17.16 Logging Out

To log out type either "logout" or "exit". Under some circumstances your request will be refused, but you should be told why. One reason for refusal is if you are not in the same shell that you logged into. Another way to log out is to press ^D. Since ^D is also used for other purposes, you may not want it to log you out. If you set IGNOREEOF in the Bash shell then ^D will no longer log you out.

17.17 Chatting between Terminals, Spying

If two persons logged into terminals on the same host computer want to chat with each other they may use the "write" or the "talk" (better) program. One may prevent anyone (except the superuser) from writing (sending messages) to their terminal by using the "mesg" command.

For spying on what someone else is doing at their terminal use the "ttysnoop" program. In "ttysnoop" the two terminals have the same status and anything typed on either keyboard appears on both screens (in the same location). So if you're really spying and don't want to be detected, you shouldn't type anything.

"ttysnoop" can be used for training with instructor and trainee sitting side-by-side, each at their own terminal. The instructor may watch what the trainee is typing and can correct any mistakes by typing it correctly. The trainee can watch what the instructor types and then try typing it. It's just like they used one terminal with both people having their hands on the keyboard at the same time.

There's one shortcoming to "ttysnoop" and that is that the terminals involved should all be (or emulate) the same type of terminal (such as vt100). Since the "Linux" emulation done by a console (monitor) and the "minicom" (or "picocom") emulation are close to vt100 one may use ttysnoop using two PCs, one running "minicom" which emulates a terminal.

There's a non-free program called "DoubleVision" that is something like ttysnoop but does much more. Terminals may be of different types and it can remember and playback sessions on terminals so you can observe what happened in the past. The webpage is at http://www.tridia.com.

17.18 Sharing the Serial Port

It's possible to use the same serial port for both a text-terminal and another serial device such as a printer or modem. Making the physical connection is easy using one of these methods:

When you are not using the serial port for a terminal, then you need to make sure that no characters intended for the terminal are sent to the other device by mistake. One unsafe way to do this is to let the programs running on the terminal keep running, provided they don't send out anything for the terminal when you are using the other device. This sometimes works since a terminal running on a serial port doesn't prevent another program (process) from opening the same port. This sometimes works if the other device is a printer. But if the other device should send bytes to the serial port on the computer, then the program(s) for the terminal which are still running on the port will often send back some bytes for the terminal which will actually go to the other device as garbage.

To avoid this, it's best to kill all programs (processes) running on the terminal before using the other device. This is not quite as easy as it sounds. You normally have a shell (such as Bash) running on the port and if you kill Bash (by logging out for example) then the program "getty" will start up on the port to try to log you in again. If you kill getty, it will respawn and start up again. So at first glance it seems impossible to kill all processes on the terminal's serial port.

One way to work around this problem is to switch runlevels so that no getty program or shell is running on the port. For the runlevel fix, you may create another runlevel in which no getty program runs on the port. Then you enter this new runlevel and use the serial port for something else. To set this up you need to edit /etc/inittab and check and/or set the runlevels at which getty runs. For example the line: "S1:23:respawn:/sbin/getty ..." means that getty will run (on ttyS1) in runlevels 2 and 3. Now you could have it only run in level 2 (by deleting "3") and then go to runlevel 3 when you want to use the other serial device. Thus to use the serial port for something else, the super-user would type "init 3" to switch to runlevel 3. Type "init 2" to get back to runlevel 2. Note that each runlevel may have a different set of initialization scripts but you can change this if you want, so that the same scripts are run in both runlevels. How the scripts and runlevels work are distribution dependent. For the Debian distribution, the explanation of this is in /usr/doc/sysvinit, but also look in /usr/share/doc.

There's also the problem of the stty configuration of the port. When the port is being used for the terminal it has certain configurations but when say "init 3" is used to switch runlevels and disable getty on the port, the original (boot-time) configuration of the port is not restored. You are likely to wind up with the port configured in a "raw" mode. This means that the serial port likely needs to be fully reconfigured by stty, either by a script you write or by the next application which runs on the port. Some applications such as printing from the serial port may not capable of fully reconfiguring. The obsolete version of /etc/printcap could only partially reconfigure (but the new one under "lprng" can). Thus you might need to write a script to do it. The stty configuration of a terminal will be different depending on whether a shell is running on it, whether it's at the "login" prompt, etc. Thus the stty configuration after switching runlevels may vary.

17.19 Browsers for Text-Terminals

See 2005 Text Mode Browser Roundup for a review of text browsers.

The "lynx" browser works correctly with all text terminals. There are some other text browsers: "w3m", "links2" (formerly "links", and "elinks" that only work perfectly with the Linux console, xterm, or vt100 terminals. But links2 and elinks will work with any terminal by classifying the type as dumb like the first terminals. However, such an interface is slower.

The "netrik" browser requires a color terminal. For "links2" and "elinks" you must set your terminal to 8-bits with no parity. (I filed a bug report years ago for elinks since it should work with parity and finally in 2008 I got a message that it was fixed in version 0.13 and might become fixed in 0.11 and 0.12 also). All (including netrik ??) support ssl (secure socket layer) for encoded communication.

"w3m", "links2", and "elinks" overcome some of the "lynx" deficiencies. "elinks" is just a more advanced "links". They can usually display tables better and can display frames side-by-side. Unfortunately, the width of what they try to display (for tables and frames) is often wider than the terminal width so the text may run off the right side of the screen. This requires scrolling sideways to see everything. Doing this may cause the names of the table rows to disappear from the screen. So in some cases, using "lynx" may be better.

Unfortunately "w3m", "links2", and "elinks" don't have numbered links like lynx does, nor do they have good support for cookies. Support for Javascript may be a problem. Elinks and netrik have partial support. Links2 also has support (full ?). Both netrik and links2 has a graphic mode for use in X Window.

There are still other text browser projects. Some of them seem to be dead.

Next Previous Contents Text-Terminal-HOWTO-18.html0000644000160500001440000002263712117203376014611 0ustar gfergusers Text-Terminal-HOWTO: Special Uses for a Terminal Next Previous Contents

18. Special Uses for a Terminal

18.1 Make a Serial Terminal the Console

This will turn a text-terminal (or emulator PC) into a "serial console". Many messages from the system are normally only sent to the console (the PC monitor). Some of the messages sent to the console at boot-time may also be seen on any terminal after the boot succeeds by typing the command: dmesg. If the boot failed this will not be of any use since the terminal can't work without an operating system. It's possible to modify the Linux kernel so as to make a terminal serve as the console and receive all the messages from Linux intended for the console. Unfortunately, the messages from the BIOS (which display on the monitor when a PC is first started) will not display on this terminal (but still display on the monitor).

There's a Remote-Serial-Console-HOWTO on this topic. Some people use a serial console when they run a PC without a monitor or keyboard. Normally, a PC will not start up without a keyboard and video card but some BIOSs permit it. If you are lucky enough to have such a BIOS that supports "console re-direct" you will likely then need to setup the BIOS using the CMOS menus when you start your PC.

The method of creating a "serial console" depends on your kernel version. In any case serial support needs to be compiled into the kernel and not supplied as a module.

For Kernels 2.2 or higher

The instructions for creating a serial-console are included with the kernel documentation in: Documentation/serial-console.txt. Kernel 2.4+ has better documentation and mentions the need to run getty on the serial port. Normally, the device /dev/console is linked to tty0 (the PC console). For a serial-console you create a new /dev/console by

mknod -m 622 console c 5 1
You must also put statements regarding the serial-console into /etc/lilo.conf and then run lilo. This is because the equivalent of "setserial" needs to be run early before the kernel is loaded so that the serial-console can display the booting. See the above mentioned kernel documentation and the man page for lilo.conf for more details.

Here is an example /etc/lilo.conf file contents (for ttyS0):

boot = /dev/sda
vga = normal # force sane state
install = /boot/boot.b
message = /boot/message
image = /vmlinuz
root = /dev/sda1
label = console
serial = 0,9600n8
append = "console=ttyS0"

The same PC may have more than one serial console but the last console mentioned in the "append" statement becomes the main console that you interact with ?? See the kernel docs (but it's not too clear).

Serial-Console For Kernels before 2.2

The Linux Journal in April 1997 had an article on patching the Linux kernel. You add a couple of #defines at the start of src/linux/drivers/char/console.c:

#define SERIAL_ECHO_PORT 0x2f8  /* Serial port address  */

The following was not in the Linux Journal article.
In kernel 2.+ (and earlier ??) you need to also set the baud
rate (unless 9600 is OK).  Find these 2 lines:

serial_echo_outb(0x00, UART_DLM); /* 9600 baud */
serial_echo_outb(0x0c, UART_DLL);

Change 0x0c in the line above (depending on the baud rate you want):

115200 baud: 0x01       19200 baud: 0x06        2400 baud: 0x30
57600 baud: 0x02         9600 baud: 0x0c        1200 baud: 0x60
38400 baud: 0x03         4800 baud: 0x18

If you currently use the console to select which operating system to boot (using LILO), but would like to do this from a terminal, then you need to add a line to the /etc/lilo.conf file. See the manual page for lilo.conf and search for "serial=".

18.2 Run Linux without a Monitor

One way to do this is to just use a terminal (serial console) for the monitor See Make a Serial Terminal the Console. You may still need a video card since many BIOSs require one to get the PC started. Your BIOS may also require a keyboard to get started or it may have an option where you can set the BIOS not to require a keyboard.

If you boot without a monitor, make sure that the boot loader (such as LILO or GRUB) doesn't try to present any image on the screen. A text-terminal can't display it and the booting may hang.

If you have a keyboardless terminal, it can also be used as a monitor by use of the ttysnoop program. As of yet, it doesn't work like a console since it doesn't get all the initial boot-time messages. See Use a Keyboardless Terminal as the Monitor

18.3 Use a Keyboardless Terminal as the Monitor

How it works

While you might think that a terminal without a keyboard is useless it is possible to use it as the monitor and type on the PC's own keyboard. This may be done by using the spy program ttysnoop. This program permits a person at one terminal to spy on (or snoop) what someone else is typing at another terminal (or the PC console-monitor).

Now suppose you are typing away at the monitor tty1. Imagine that someone with a terminal on ttyS2 is spying on you (with ttysnoop) and has a screen that looks just like your screen. Everything you type at tty1 also displays on ttyS2. Now move the spy terminal (on ttyS2) so it is side-by-side with your monitor (on tty1). Everything you type on the PC keyboard will now display on the two screens in front of you: the monitor and the spy terminal. Now just look only at the spy terminal as you type. Disconnect both the monitor and the terminal keyboard since you're not using either. Thus you are now using a keyboardless terminal as a monitor. What a simple but clever solution!

One possible problem (which turns out to be no problem at all) is that normally, the type of spy terminal should be the same as the type of terminal being spied upon. Since the monitor is normally declared as a terminal of type "linux" (which is close to vt100), you might think that the real terminal should also be (or at least emulate) a vt100. Not necessarily so! For example, if you have a wyse60 terminal you simply falsely declare that you have a wyse terminal on tty1 (tell the getty program for tty1 that it's a wyse60).

Here's why you can get away with this. Go back the scenario where you have both the monitor and the wyse60 terminal in front of you, both displaying the same thing (or trying to). Ttysnoop will be sending the wyse60 the same bytes as are going to the monitor. If you've falsely claimed that the monitor is a wyse60, then you'll have wyse60 escape sequences going to both the monitor and the wyse60 terminal (via ttysnoops). The display on the wyse60 is fine but the display on the monitor is corrupted since it's getting wyse60 escape sequences. Since you will not use the monitor (and are about to disconnect it) this corruption is never a problem (you simply don't see it).

Example configuration

This is not the ideal setup since ttysnoop runs so late that the login prompt doesn't appear. This example is for a wyse60 terminal on ttyS2 and the missing monitor/PC-keyboard on tty1. It uses the agetty program for getty as supplied by the Debian distribution. Your getty may require a different format.

In /etc/inittab:

1:2345:respawn:/sbin/getty 38400 tty1 wyse60 -ln /usr/sbin/ttysnoops

Note that ttysnoop/ttysnoops is a client-server combo so the "s" is not a typo. If you don't use -n you may not see a login prompt on the terminal. With no -n, agetty issues the prompt before the ttysnoop is activated. With -n, agetty doesn't issue the prompt (but login does instead). If you use -n, agetty will no longer automatically detect parity but if you don't use parity all is OK.

In /etc/snooptab:

# tty       snoopdev      type    execpgm
tty1        /dev/ttyS3    init    /usr/local/bin/sterm
In the above, a script named sterm is used to run the stty program. You may not need this or may want to use it for another purpose. Here's the example sterm script in /usr/local/bin/sterm:

stty rows 24
/bin/login $@

Next Previous Contents Text-Terminal-HOWTO-19.html0000644000160500001440000010132512117203376014602 0ustar gfergusers Text-Terminal-HOWTO: Trouble-Shooting Next Previous Contents

19. Trouble-Shooting

If you suspect that the problem is a hardware problem, see the Repair and Diagnose section. If it's the keyboard see Keyboards. If it responds incorrectly (if at all) to what you type. see Corrupted Terminal Interface. If the problem involves the serial port itself see the Serial-HOWTO.

Here is a list of possible problems:

There are two cases where the terminal goes bad. One is when it's been recently working OK and suddenly goes bad. This is discussed in the next sub-section. The other case is where things don't work right just after you install a terminal. For this case you may skip over the next section.

19.1 Terminal Was Working OK

When a formerly working terminal suddenly goes bad it is often easy to find the problem. That's because (except for hardware failures) the problem is likely due to something that you did (or something the software that you used did).

The problem may be obvious such as an error message when the terminal is first turned on. If it makes a strange noise it likely needs repair. See Repair & Diagnose. First, think about what has been done or changed recently as it's likely the cause of the problem. Did the problem happen just after new system software was installed or after a change in the configuration?

If the terminal isn't responding correctly (if at all) to what you type to it, you may have a Corrupted Terminal Interface.

19.2 Terminal Newly Installed

If you've just connected up a terminal to a computer per instructions and it doesn't work this section is for you. If a terminal that formerly worked OK doesn't work now then see Terminal Was Working OK If you suspect that the serial port on your computer may be defective you might try running a diagnostic test program on it. At present (June 1998) it seems that Linux doesn't yet have such a diagnostic program so you may need to run diagnostics under MS DOS/Windows. There are some programs to monitor the various serial lines such at DTR, CTS, etc. and this may help. See Serial Monitoring/Diagnostics

One approach is to first see if the terminal will work by trying to copy a file to the terminal (cp my_file /dev/ttyS?) under the most simple situation. This means with the modem control lines disabled and at a show speed that doesn't need flow control (make sure that any hardware flow control is disabled). If this copy works, then make the situation a little more complicated and see if it still works, etc., etc. When the trouble appears just after you made a change, then that change is likely the source of the trouble. Actually, its more efficient (but more complex) to jump from the simple situation to about half way to the final configuration so that the test eliminates about half of the remaining possible causes of the problem. Then repeat this methodology for the next test. This way it would only take about 10 tests to find the cause out of a thousand possible causes. You should deviate a little from this method based on hunches and clues.

19.3 Is the Terminal OK ?

Many terminals will start up with some words on the screen. If these words convey no error message, it's probably OK. If there is no sign of power (a dark screen, etc.) re-plug in the computer power cord at both ends. Make sure there is power at the wall jack (or at the extension cord end). Try another power cord if you have one. Make sure the terminal is turned on and that its fuse is not blown. A blank (or dim) screen may sometimes be fixed by just turning up the brightness and contrast using knobs or a keyboard key in set-up mode.

A terminal that's been stored for a long time may take a while to "warm up" as the electrolytic capacitors heal themselves under voltage. If it still won't work See Repair & Diagnose for tips on repairing it.

If the terminal starts up OK, but you suspect that something may be wrong with it, go into "local mode" where is works like a typewriter and try typing on it. See Local Mode. Before you have trouble, you should find out if your terminal displays error messages if the hardware is bad. One way to test a terminal for this is to turn it on with the keyboard unplugged and see if it displays an error message.

19.4 Missing Text

If several lines or text displays on the terminal OK and then it stops without finishing (in the middle of a word, etc.) or if big chunks of text are missing, you likely have a problem with flow control. If you can't figure out right away what's causing it, decrease the speed. If that fixes it, it's likely a flow control problem. It may be that flow control is not working at all due to failure to configure it correctly, or due to incorrect cable wiring (for hardware flow control). See Flow Control

If you can type OK at the terminal but when text is sent to the terminal, only about 1 in every 16 characters sent gets thru, then you may have given the wrong UART to setserial. This will happen if the port is an obsolete 16550 (or lower) but you've told setserial it's a 16550A or higher.

If single characters are missing, perhaps the serial port is being overrun by too fast a speed. Try a slower baud rate.

If your device is under 1200 baud (probably a very slow old hard-copy terminal or printer) and the text gets truncated, then the problem may be in the serial device driver. See Printing-HOWTO under "Serial devices" on how to fix this.

19.5 All Keys Work Erratically; Must Hit a Key a Few Times

This is where you need to hit a key a few times before it works (and see the letter you typed on the screen). If you type a word, some (or even all) of the letters may be missing on the screen. If letters are missing from a command it doesn't work and even if all letters are present you may need to hit the return-key several times to get the command to execute.

This may be due to two different processes opening the serial port. Both try to read what you type. Sometimes one process (the right one --perhaps the shell) reads what you type and at other times the other process reads what you type. An example is where the other process is for a serial mouse (such as gpm) which doesn't echo what you type. So another process running on the same ttySx is eating some of what you type. To fix this, use "ps -alx" to see what else is running on your ttySx and kill that process.

You might think that lockfiles would prevent two programs from using the same serial port at the same time. But neither the terminal nor the gpm mouse program uses lockfiles. Since others may need to write to your terminal, it's reasonable not to use lockfiles. See Lock-Files in the Serial-HOWTO.

19.6 ... respawning too fast: disabled for 5 minutes

What's happening

You see a message on the console like: "Getty respawning too fast: disabled for 5 minutes". Instead of "Getty" it may display a label (such as: Id "S2") where S2 is the label for the line in /etc/inittab from where from where getty was called.

When getty starts up, it tries to send a login message to the serial port. But if there is something seriously wrong, getty will be immediately killed. Since the /etc/inittab file line for getty says to "respawn", getty is started again, only to be killed again, etc. Thus getty rapidly respawns over and over. But the operating system intervenes and stops this nonsense (for 5 minutes). The following sections show possible causes and fixes.

Getty line in /etc/inittab file incorrect

Make sure the line which calls getty in /etc/inittab is correct. A typo in "ttySx" (or "DTxxxx" for uugetty) or in "getty" may cause this problem.

No modem control signal

If the terminal doesn't send the PC a CD signal on one of the pins of the serial port, getty will be killed unless the "local" option has been used with getty. So a quick fix is to just use a "local" option (-L for agetty, "CLOCAL" in /etc/gettydefs for getty_ps).

Another approach is to determine why CD is not being asserted. In many cases the cable to the terminal simply doesn't have a wire for the CD pin so you must use the "local" option. If there is a wire for the CD pin then there may not be any signal on it until the terminal is powered on. Note that the CD pin signal is sometimes supplied by the DTR pin of the terminal (or the PC) by using jumper wires inside the connector.

No such serial device

If the device (such as /dev/ttyS2) is bogus (doesn't physically exist or has been disabled), then getty will be killed. You may use "scanport" (Debian only ??) and/or "setserial" to probe for the device or try another ttyS. Perhaps the device has been disabled in the CMOS. See "Serial-HOWTO".

No serial support

Linux provides serial support either by selecting it when compiling the kernel or by loading the serial module: serial.o. This "respawning" error happens if serial support has neither been built into the kernel nor provided by a serial module. You many use the "lsmod" command to see if the serial module is loaded. To see if serial support is built into the kernel, check a kernel configuration file (in /boot, in the source tree, etc.)

Key shorted

Another possible cause of getty respawning too rapidly is if a keyboard key is shorted. This can happen if the key gets stuck in the down position. With auto-repeat enabled, this "types" thousands of characters to the login prompt. Look for a screen filled with all the same character (in some cases, with 2 or more different characters).

19.7 Fails Just After Login

If you can login OK but then you can't use the terminal it may be because the starting of the login shell has reconfigured the terminal (to an incorrect setting) by a command which someone put into one of the files that are run when you login and a shell starts. These files include /etc/profile and ~/.bashrc. Look for a command starting with "stty" or "setserial" and make sure that it's correct. Even if it's done OK in one initialization file, it may be reset incorrectly in another initialization file that you are not aware of. Ways to get into the systems to fix it are to use another terminal or console, use a rescue diskette, or type: "linux single" at the lilo prompt which puts you into single user mode without running startup files.

19.8 Can't Login

If you get a login prompt but get no response (or perhaps a garbled response) to your login attempts a possible cause is that the communication is bad one-way from the terminal to the computer. It could be a bad or mis-wired cable/connector. If you're not already using the "local" option with getty, do so to disable the modem control lines. See Getty (used in /etc/inittab). You might also disable hardware flow control (stty -crtscts) if it was enabled. If it now works OK then your modem control lines are likely either not wired correctly or there's a mistake in your set-up. Some terminals allow setting different values (such as baud rate) for send and receive so the receive could be OK but the send bad.

You should also try at another terminal (such as the console) "stty -F /dev/ttyS1" (or ttyS whatever) to see that it's set up correctly. It will often be in raw mode (and this is probably OK) with -icanon and -echo etc. If the terminal incorrectly set at half-duplex (HDX), then one set of the characters you see when you type are coming from the terminal itself. If the characters are doubled, then the echos from the computer are OK and you may switch to full-duplex to fix this. But if half-duplex is set and you only see what looks like normal "echos", then they are not coming from the computer as they should be.

If you get a message saying something like "login failed" then if there is no error in typing or in the password, there may be some restrictions on logins which will not allow you to log in. Unfortunately, this message, may not tell you why it failed. See Login Restrictions

19.9 Garbled Login Prompt

This may be due to using the wrong character set, transmission errors due to too high of a baud rate, incompatible baud rates, incompatible parity, or the wrong number of bits per byte. If it's a variety of strange characters you have the wrong character set or a high order bit is being set by mistake. If words are misspelled, try a lower baud rate. For baud, parity, or bits/character incompatibilities you see a lot of the same "error character" which represents a real character that can't be displayed correctly due to an error in parity or baud rate. The "error character" may be an upside-down question mark or some other strange looking character such as a rectangle.

If you are using agetty (often just named getty), the agetty program will detect and set parity and/or bits/character if you type something. Try it with a return to see if it fixes it.

19.10 No Login Prompt

If there's no login prompt displayed after hitting the return-key a few times then check the following: Use the "top" or "ps" programs to make sure that a getty (or login) process is actually running on the terminal. Is the terminal getting power? Is the null modem cable plugged in to the correct ports on both the terminal and computer?

Check that getty isn't hanging because there is no CD signal (or no CD wire in the cable). If such a CD signal doesn't exist you should have specified "local" to getty by either:

If getty (or login) isn't running, carefully check the format for calling getty in /etc/inittab. Make sure that it includes the current runlevel (shown by typing the command "runlevel") and that it is valid for your flavor of getty. Sometimes killing getty or login (it will restart automatically) helps.

Terminal was working OK

Although hardware failures are possible, the problem is likely due to something that someone did by mistake. Did someone do something that might have loosened a cable? Did someone modify /etc/inittab or make some other change to the software so as to prevent terminal login? If this doesn't reveal the cause, continue reading.

More diagnose

The above should solve most cases (unless you've just installed a terminal). Other causes include defective hardware or cables (must be file-transfer), terminal setup at wrong baud-rate, terminal in local mode, etc. At this point two different avenues of approach are (you may pursue more than one at a time).

Diagnose problem from the console

One test is to try to copy a something to the terminal (It might be a good idea to try this near the start of the installation process before setting up getty). You may use the Linux copy command such as:"cp file_name /dev/ttyS1". Or your could use: "echo any_word > /dev/ttySx". If it doesn't work, use stty to make the interface as simple as possible with everything disabled (such as hardware flow control: -crtscts; parity, and modem control signals: clocal). Be sure the baud rates and the bits/byte are the same. If nothing happens verify that the port is alive with a voltmeter per the next section.

Measure voltages

If you have a voltmeter handy check for a negative voltage (-4v to -15v) at pin 3 or 2 (receive data) at the terminal side of the file-transfer cable. The positive lead of the meter should be connected to a good ground (a metal connector on the end of the cable may not be grounded). If there is no such negative voltage then check for it at the transmit pin (TxD) on the computer (see DB9-DB25 for the pin-out). If it's present there but not at the receive pin (RxD) at the terminal, then the cable is bad (loose connection, broken wire, or not a file-transfer aka null-modem). If this voltage is absent at the computer, then its serial port is dead. Test it with a software diagnostic test or replace it.

If the serial port is alive, you may want to send a file to it (with modem controls disabled) and watch the signal on a voltmeter (or other electronic gadget). To check for a transmitted signal with a voltmeter, check for a steady negative voltage when the line is idle. Then start sending a file (or start getty). On an analog meter you should see the needle dropping to almost 0 and fluttering about 0 as it measures short-run averages of the bit stream. On a digital meter you will not see the fluctuations as well but you can switch to the AC scale to see the AC voltage created by the flow of bits. If your meter fails to block out DC on the AC scale (the default of most analog meters), then you could get a false high AC reading when looking at the idle DC of -12v (or -5v) on the AC scale. Without a meter, you could connect a known good device (such as another terminal or an external modem) to the serial port and see if it works OK.

19.11 Displays Foreign/Weird Characters/Symbols

Don't confuse this with Displays Escape Sequences. If what you type or see on the screen is not what's expected but looks like a foreign alphabet, math symbols, line-drawing character, etc. then it could be that the many of bytes that are sent to your terminal have the high order bit set (when it shouldn't be). You are looking at the character set (or part of a character set) which has the high order bit set. This may happen if you have the baud rate wrong or parity set wrong (per stty). If you have parity set per stty but inside the terminal it's 8-bit no-parity, then the high order bit (= parity bit) will often be erroneously set. Try stty -F /dev/ttyS? from another terminal to check if the baud rate and parity are correct.

Perhaps the wrong character set (font) has been installed. An erroneous escape sequence sent to the terminal could have switched character sets. If you are using the mapchan program to change the keyboard mapping, it could be incorrect.

19.12 Displays Escape Sequences

You may see something like "5;35H22,1" or "3;4v" or "1;24r" or "^[[21;6H", etc., etc. Of course, the numbers and letters will be different. They will be scattered about (either randomly or in a strange sense of order). The display will look a mess and will likely have other defects. Some application and commands will result in corrupted displays.

What you see are escape sequences (or fragments of them) that were sent to your terminal in order to control it, but your terminal didn't recognize them and passed them on to the screen. It's likely that the program you're using erroneously thinks you are using another type of terminal. Thus it sends escape sequences that your terminal doesn't understand. This can sometimes do strange things to your display. Check that the TERM environment variable is set correctly (type: echo $TERM).


The problem of getting TERM right can be a bit more complex if you use telnet. Telnet doesn't emulate a terminal but passes the value of your TERM variable to the remote computer. If the remote computer doesn't support your type of terminal, or changes the value of TERM to a wrong value (on the remote) then there's trouble. Telnet should initially set the value of TERM correctly on the remote. But changes to the value of TERM (on the remote) could be caused by an incorrect shell configuration file there. The first thing to do is to check the value of TERM, both on your computer and on the remote. The above is overly simplified since it's possible for your telnet client to present the remote server with a list of possible TERM values which your computer supports (if telnet knows that your computer can emulate more than one terminal type).

Terminal set to display escape sequences

Another possible cause is that your terminal happens to be in a special mode where it displays the escape sequences instead of executing them. Then you'll also see them on the screen but they will display in an orderly fashion. This mode is more precisely, one that displays control codes. But since each escape sequence starts with a control code (the "escape" character), the whole escape sequence is not recognized by the terminal and is passed along to the screen. See Control Codes.

19.13 Slow: pauses of several seconds between bursts of characters

You likely have mis-set interrupts> See the Serial-HOWTO section starting with "Slow:"

19.14 Cursor Jumps

This error happens when you expect the cursor to move to the next character but instead it seems to jump to another character. It can happen in the vim editor when you've selected "showmatch" to highlight matching brackets (or parentheses). There is nothing wrong with the terminal and the cursor isn't jumping, but it looks like it is.

What is happening is that the cursor is reverse video and the highlighting is also reverse video. So suppose you highlight (or emphasize) a character by reverse video and then put a reverse-video cursor over it. The cursor's reverse video will then reverse the existing reverse video of the character and result in normal video. The result is that both the cursor and character highlighting have disappeared for that character and the cursor is invisible (until you move it to a non-highlighted character).

OK, so the cursor suddenly disappears, but what makes it jump? For the vim "showmatch" when you move the cursor to an opening bracket it also highlights the closing bracket. Thus the closing bracket suddenly becomes reverse video and it looks just like the cursor has jumped there, but it hasn't. Similar "illusions" happen when you move the cursor to a closing bracket (or parenthesis). This illusion when you reverse reverse-video happens in other cases besides the vim example just presented.

19.15 Terminal doesn't scroll

One reason may be that something is wrong with terminfo. Another reason could be that you are outside the scrolling region set for the terminal. Some stupid programs just assume that your terminal has 24 lines and set the scrolling region for 24 lines (by an escape sequence sent to the terminal) without consulting terminfo to see how many lines there actually are. Then when you use another program it may leave the cursor on line 25 where it becomes trapped and the terminal will not scroll. To avoid this problem, create an environment variable "export LINES=25" and also "stty -F /dev/ttySx rows 25". Then the programs that assume 24 lines will hopefully use 25 lines set the scrolling region accordingly.

19.16 Serial Monitoring/Diagnostics


You may already have the above programs. If not, go to Serial Software. When using these, bear in mind that what you see is the state of the lines at the host computer. The situation at the terminal will be different since some wires are often missing from cables while other wires cross over. As of June 1998, I know of no diagnostic program in Linux for the serial port.

19.17 Local Mode

In local mode, the terminal disconnects from the computer and behaves like a typewriter (only it doesn't type on paper but on the screen). Going back into on-line mode reconnects to the computer allowing you to resume activities at the same point where you left off when you went into "local". This is useful both for testing the terminal and for educational purposes. For some terminals there is no "local mode" but "block mode" may substitute for it. If there is no "block mode", "half duplex" mode might work, except that what you type gets sent to the computer also. In this case the computer may echo the characters sent to it resulting in two characters displayed on the screen for every character you type. To prevent this you could shut down the computer, disconnect the RS-232 cable, etc.

When in local mode you may type escape sequences (starting with the ESC key) and observe what they do. If the terminal doesn't work correctly in local mode, it's unlikely that it will work correctly when connected to the computer. If you're not exactly sure what an escape sequence does, you can try it out in local mode. You might also use it for trying out a terminal that is for sale. To get into local mode on some terminals you first enter set-up mode and then select "local" from a menu (or press a certain key). See Getting Into Set-Up (Configuration) Mode.

19.18 Serial Electrical Test Equipment

Breakout Gadgets, etc.



Measuring voltages



Taste voltage



Next Previous Contents Text-Terminal-HOWTO-1.html0000644000160500001440000002723412117203375014516 0ustar gfergusers Text-Terminal-HOWTO: Introduction Next Previous Contents

1. Introduction

For a quick attempt to install a text-terminal see Quick Install.

1.1 Copyright, Trademarks, Disclaimer, & Credits


Copyright 1998-2010 by David S. Lawyer. mailto:dave@lafn.org


  3. Give due credit to previous authors and major contributors.







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 of Text-Terminal-HOWTO had about 25 changes (and error corrections) suggested by Alessandro Rubini. For 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.

1.2 Future Plans: You Can Help

The author is looking for someone to take over maintaining this howto. Since real text terminals are pretty much obsolete, there is not a lot of work to do except that links sometimes disappear and automatically finding devices such a dumb terminals on a serial port may not work right. One project is to rewrite this howto oriented towards text-terminal emulation with the command line interface. Another project would be to start with the brief overview of GUI terminals in this HOWTO and create a new and up-to-date HOWTO on thin clients or the like.

Please let me know of any errors in facts, opinions, logic, spelling, grammar, clarity, links, etc. But first, if the date is over a couple of years 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 have solved this problem would be for terminal manufacturers to put their manuals on the Internet but they never did. Except that Wyse made available some of their user manuals and someone scanned old VT-100 manuals.

1.3 New Versions of this HOWTO

New versions of the Text-Terminal-HOWTO should be released every couple of years. 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.43 March 2013 .

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

1.4 Related HOWTOs

Go to the nearest mirror site (per above) to get HOWTOs.

1.5 Terminology Used in this Document

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.

1.6 What is a Terminal ?

A terminal consists of a screen and keyboard that one uses to communicate remotely with a computer (the host). One uses it almost like it was a personal computer but the terminal is remote from its host computer that it communicates with (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. Originally terminals were stand-alone devices with no computational ability and thus they were once much cheaper in cost than computers. They had no pictures or audio, but could only display text and were thus called "text terminals". Today, the cost of PC computers is so low that one may use a PC like a text terminal by running a software program to make it behave like an old text terminal. You formerly found real text terminals at libraries and schools.

1.7 Real Text Terminals

In the olden days of mainframes, from the mid 1970's to the mid 1980's, most communication with large computers was done by people sitting in front of real text-terminals. And in the 1970's, before the advent of personal computers, it was the only way to interactively communicate with any computer. 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, the speed slow, and little software was available to support such graphics.

Today, real terminals are becoming rarities for most all computer users. But there is still some specialized uses for them as point-of-sale devices and for access to mainframes and servers where graphics and pictures are not needed. However, if a text terminal is needed people will sometimes use a personal computer to emulate a terminal.

Almost everyone who uses Linux also 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. However in these cases, one doesn't need most of the information provided by this HOWTO since such emulation is automatically set up for the user. However if one emulates a terminal using a software program and then connects that emulated terminal to another computer via a serial port cable, then this HOWTO should be more useful (provided your PC has a serial port on it --almost all recent PCs made after 2009 didn't have them anymore).

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 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 own 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 another real terminal and use the same computer simultaneously with others. Such multi-user interfaces are not "clients" and a server..

Next Previous Contents Text-Terminal-HOWTO-20.html0000644000160500001440000006403412117203376014577 0ustar gfergusers Text-Terminal-HOWTO: Repair & Diagnose Next Previous Contents

20. Repair & Diagnose


20.1 Repair Books & Websites





20.2 Safety



20.3 Appearance of Display




20.4 Diagnose

Terminal Made a Noise or Smoked






Terminal Made No Noise




20.5 Detective work




20.6 Error Messages on the Screen


Keyboard Error


Checksum Error in NVR


20.7 Capacitors




20.8 Keyboards



How They Work


Modern vs Old Keyboards


One Press Types 2 Different Characters


Keyboard doesn't work at all


Typing b displays bb, etc. (doubled)


Row upon row of the same character appears


Key sticks in down position (individual switches)





Key electrically shorted


Liquid spilled on the keyboard


Cleaning keyboard contacts

Keyboards with membranes


Keyboards with individual switches










Next Previous Contents Text-Terminal-HOWTO-21.html0000644000160500001440000002262712117203376014602 0ustar gfergusers Text-Terminal-HOWTO: Appendix A: General Next Previous Contents

21. Appendix A: General

21.1 List of Linux Terminal Commands

Sending a command to the terminal

Configuring the terminal device driver



21.2 The Internet and Books

Terminal Info on the Internet

In the first decade of the 20th century, http://www.cs.utk.edu/ shuford/terminal_index.html was Shuford's Website at the University of Tennessee. It was the major sit for information about text terminals but is now (2013) defunct. Perhaps one can find it archived on the "Wayback" machine. http://www.cs.utk.edu/ shuford/terminal/repair_hints_news.txt was Shuford's repair archive of newsgroup postings on terminal repair. See below for the vt100 part of this website which is still on the internet.

Books related to terminals

Entire books on terminals

As far as I know, there is no satisfactory book on text terminals Although this HOWTO has been published as a book, I don't suggest that that you buy it if you have access to the online version which I'm improving on every few months or so. The following are mainly of historical interest:

The "HANDBOOK ... " presents brief specifications of over 100 different models of antique terminals made in the early 1970's by over 60 different companies. It also explains how they work physically but has a diagram for a CRT which erroneously shows electrostatic deflection of the electron beam (p. 36). Terminals actually used magnetic deflection (even in the 1970's). This book explains a number of advanced technical concepts such as "random scan" and "color penetration principle".

The "COMMUNICATING ... " book in contrast to the "Handbook ... " ignores the physical and electronic details of terminals. It has an entire chapter explaining binary numbers (which is not needed in a book on terminals since this information is widely available elsewhere). It seems to mostly cover old IBM terminals (mainly the 3270) in block and synchronous modes of operation. It's of little use for the commonly used ANSI terminals used today on Unix-like systems. Although it does discuss them a little it doesn't show the various wiring schemes used to connect them to serial ports.

Books with chapters on terminals

These chapters cover almost nothing about the terminals themselves and their capabilities. Rather, these chapters are mostly about how to set up the computer (and its terminal driver) to work with terminals. Due to the differences of different Unix-like systems, much of the information does not not apply to Linux.

The "UNIX POWER TOOLS" book has 3 short chapters on text terminals. It covers less ground than this HOWTO but gives more examples to help you.

The "ADVANCED PROGRAMMING ... " Chapter 11 covers only the device driver included in the operating system to deal with terminals. It explains the parameters one gives to the stty command to configure the terminal.

The "ESSENTIAL SYSTEM ..." book's chapter has more about terminals than modems. It seems well written.

21.3 Non-Linux OSs

Under Microsoft's DOS one may use the DOS command "ctty COM2" so that the DOS command line will display on a serial terminal (on COM2 in this example). Unfortunately one can then no longer use the computer monitor since MS DOS is not a multiuser operating system. Nor can more than one terminal be used. So this capability is of little (if any) benefit. If you emulate DOS under Linux with the free dosemu, it's reported that you can run several terminals (multiuser). But it's reported that PCTerm emulation doesn't work with it (yet ??).

While MS didn't create a "multiuser DOS" OS, others did. This permits the use of many terminals on one DOS PC. It's compatible with most MS-DOS software. One multiuser DOS OS is named "REAL/32". The terminal's "pcterm" emulation is used here. There also may be a "scan" (scancodes) setup mode which needs to be set. Other OSs such as PICK, PC-MOS, and Concurrent DOS were/are multiuser and support terminals.

There are 3 programs for Linux which let you run Windows applications on a Linux PC: free: Wine, non-free: VMware and NeTraverse. Can they use text-terminals under DOS? Wine can't since it doesn't have a DOS mode. The other two require you to run the MS Windows OS software as a "guest OS". The guest MS Windows OS has a DOS mode but it's not of much use for text-terminals since it's not multiuser.

For other unix-like OSs, the configuration of the host computer for terminals is usually significantly different than for Linux. Here are some links to on-line manuals for non-linux systems.

Next Previous Contents Text-Terminal-HOWTO-22.html0000644000160500001440000001527112117203376014600 0ustar gfergusers Text-Terminal-HOWTO: Appendix B: Escape Sequence Commands Terminology Next Previous Contents

22. Appendix B: Escape Sequence Commands Terminology



22.1 Esc Sequence Lists

See url url= "http://www.neoware.com/docs/teemtalk/t2k17pro.pdf" name="TeemTalk.2000 Programmer's Guide v 1.7"> in pdf format. But there are some sites that have info for certain terminals. For VT terminals see VT Manuals. Other lists have disappeared from the internet.

22.2 8-bit Control Codes


ACRONYM  FULL_NAME                      HEX     REPLACES
IND Index (down one line)               84      ESC D
NEL Next Line                           85      ESC E
RI  Reverse Index (one line up)         8D      ESC M
SS2 Single Shift 2                      8E      ESC N
SS3 Single Shift 3                      8F      ESC O
DCS Device Control String               90      ESC P
CSI Control Sequence Introducer)        9B      ESC [
ST  String Terminator                   9C      ESC \

22.3 Printer Esc

22.4 Reports


22.5 Cursor Movements



22.6 Pages (definition)


Next Previous Contents Text-Terminal-HOWTO-23.html0000644000160500001440000004671612117203376014611 0ustar gfergusers Text-Terminal-HOWTO: Appendix C: Serial Communications on EIA-232 (RS-232) Next Previous Contents


23.1 Intro to Serial Communication




23.2 Voltages

Voltage for a bit




Voltage sequence for a byte



23.3 Parity Explained




23.4 Forming a Byte (Framing)


23.5 Limitations of EIA-232

Low Speed & Short Distance



Successors to EIA-232


Line Drivers


23.6 Synchronization & Synchronous

How "Asynchronous" is Synchronized



Defining Asynchronous vs Synchronous




Synchronous Communication




23.7 Block Mode

Introduction to Block Mode



Types of Block Modes, Forms






Problems with block mode



23.8 EIA-232 (RS-232) Books


23.9 Serial Software


Next Previous Contents Text-Terminal-HOWTO-24.html0000644000160500001440000003131112117203376014573 0ustar gfergusers Text-Terminal-HOWTO: Appendix D: Notes by Brand/Model Next Previous Contents

24. Appendix D: Notes by Brand/Model

Here are notes by brand name that were too specific to a certain terminal to be put elsewhere in this HOWTO. If you have some info to contribute on a certain terminal that is not covered elsewhere, it could go here. Various models often have much in common so such common information need only be written about once. It would be nice if for each terminal model, there were a set of links linking to most of the documentation relevant to that model (including escape codes). But it hasn't been done. Note that some VT (DEC) manuals are now available on the Internet. See and VT (DEC). Wyse put the information from its manuals on the Internet but it can't be readily found now (2013).

24.1 Adds

The Adds terminal menu incorrectly used "Xon/Xoff" to mean any kind of flow control. True for which models ??

Adds, which made the Adds Viewpoint terminal, was taken over by Boundless Technologies in 1994 but they continued to use the "Adds" name.

24.2 CIT

CIT terminals were made in Japan in the 1980's for CIE Terminals. They ceased to be imported in the late 1980's. The company, CIE, still made CItoh printers (in 1997) but has no parts for its abandoned terminals. Ernie at (714) 453-9555 in Irvine CA sold (in 1997) some parts for models 224, 326, etc. but has nothing for the 80 and 101.

To save the Set-Up parameters press ^S when in Set-Up mode. cit80: Contrast: knob on rear of terminal, cit101e: Brightness: use up/down arrow keys in Set-Up mode.

24.3 IBM Terminals

Don't confuse IBM terminals with IBM PC monitors. Many IBM terminals don't use ASCII but instead use an 8-bit EBCDIC code. It's claimed that in EBCDIC the bit order of transmission is reversed from normal with the high-order bit going first. The IBM mainframe communication standards are a type of synchronous communication in block mode (sends large packets of characters). Two standards are "BISYNC" and "SNA" (which includes networking standards). Many of their terminals connect with coax cable (RG62A/U) and naive persons may think the "BNC" connecter on the terminal is for ethernet (but it's not).

While this IBM system is actually more efficient than what is normally used in Linux, terminals meeting this IBM standard will not currently work with Linux. However, some IBM terminals are asynchronous ASCII terminals and should work with Linux on PC's. The numbers 31xx may work with the exception that 317x and 319x are not ASCII terminals. Before getting an IBM terminal, make sure there is a termcap (terminfo) for it. If their isn't, it likely will not work with Linux. Even if there is a terminfo, it may not work. For example, there is a termcap for 327x but the 3270 is an EBCDIC synchronous terminal.

The 3270 series includes the 3278 (late 1970's), 3279 with color and graphics, and the 3274 terminal controller (something like the 3174). They may be used for both BISYNC and SNA. The 3290 has a split screen (splits into quarters).

The synchronous IBM terminals don't connect directly to the IBM mainframe, but connect to a "terminal controller" (sometimes called "cluster controller" or "communication controller"). Some of these controllers can convert a synchronous signal to asynchronous so that in this case a synchronous terminal could indirectly connect to a Unix-like host computer via its serial port. But there is still a major problem and that is block transmission. See section Block Mode.

IBM 3153

It's claimed that the Aux port is DCE and uses a straight-thru cable.

24.4 Teletypes

These are antiques and represent the oldest terminals. They are like remotely controlled typewriters but are large and noisy. Made by the Teletype Corp., the first models were made in the 1920's and predate the computer by over 30 years. Early models used electro-mechanical relays and rotating distributors instead of electronics. Their Baudot code was only 5-bits per character as compared to 7-bit ASCII. See the book "Small Computer Systems Handbook" by Sol Libes, Hayden Books, 1978: pp. 138-141 ("Teletypes").

24.5 VT (originally DEC, now Boundless)

Digital Equipment Corporation (DEC) made the famous VT series of terminals including the commonly emulated VT100.

In 1995 DEC sold their terminal business to Boundless Technologies. Boundless went bankrupt in 2003 but emerged from bankruptcy in 2006 as a division of "Visual Technologies". Then in 2008 they were acquired by Video Display Corporation and given to their Z-AXIS subsidiary located near Rochester, New York. The Boundless name and url have been retained.

Detailed VT terminal information, some manuals, and history is at http://www.vt100.net/.

VT220: Some have a BNC connector for video output (not for input). Sometimes people erroneously think this is for an ethernet connection.

VT510, 520, 525: Supports full DTR/DSR flow control. Some are "low emissions" models. The 520 is multi-session and the 525 has colors for highlighting.

Dorio is a lower quality model which can emulate many other terminals. The "sco unix console" is claimed to be a powerful emulation using the "scoansi" terminfo.

24.6 Links

The terminal maker Links was taken over by Wyse.

24.7 Qume

Qume was taken over by Wyse in the early 1990s.

24.8 Wyse Terminals

detailed manual-like information on old terminals see http://www.wyse.com/service/support/kbase/wyseterm.asp. This information includes specs, lists of escape sequences, part lists, FAQs, setup info, etc. Thanks to Wyse for providing this even though as of 2006 they are no longer making text terminals.

Wyse terminals were lower in cost than other brands and they captured a major share of the market. There were concerns about the quality of these terminals, especially the Wyse 50. But the large number of failure reports (other than Wyse 50) may be due in part to the large number of Wyse terminals in use.

See en.wikipedia.org/wiki/Dell_Wyse for a history of Wyse.

Wyse 50

Reported not to last very long.

Wyse 60

Display adjustments (must remove cover): Brightness VR202, Height VR302, Width VR101 (also affects height). If you want to use it in Native Personality, then the arrow-key codes will conflict with the codes used in vi (such as ^L). To fix this set "Application key mode" with ESC ~ 3. This results in the arrow keys sending 0xd0 - 0xd3. Due to a bug in the readline interface of the Bash shell, you need to edit /etc/inputrc so that the arrow keys will work in Bash. See Bugs in Bash

Wyse 85

Can emulate VT52/VT100/VT200. Press F3 for setup. After moving left/right to go a menu "icon", press space to select it. Scroll thru setup menus with up/down keys. Press F3 at any time to reenter setup (without loosing any settings).

Wyse 99-GT

Here is the setup Menus of the Wyse99GT (late 1980's). Note that TERM means "termination" (character) and not "terminal".

  WYSE 99-GT Terminal Set-Up as used at the University of CA, Irvine

                by David Lawyer, April 1990

                        F1 DISP:
COLUMNS=80              LINES=24                CELL SIZE=10 X 13
                        F2  GENERAL:
                        F3 KEYBRD:
RETURN=CR               ENTER=CR                FUNCT KEY=HOLD
                        F4 COMM:
(There is a main port (Modem=MDM) and an Auxiliary Port (AUX)
                        F5 MISC 1:
                        F6 MISC 2:
LOCAL=OFF               SEND=ALL                PRINT=NATIONAL
PRINT MODE=NORMAL       VT100 ID=VT100          POUND=US
F7 TABS: You should see several "T" characters spaced 8 dots apart.
    If you don't, hit backspace.
F8 F/KEYS: Normally you will see no definitions for the Function Keys
    here (unless someone has set them up and saved them).  This means that
    they will normally generate their default settings (not displayed here).
    <ctrl><F5> shows the "user defined definition" of the F5 key, etc.
F9 A/BACK: Normally not defined: ANSWERBACK =
F10 EXIT: Selecting "DEFAULT ALL" will make the factory default settings
    the default.

HINTS on use of WY-99GT User's Guide: Note that much that is missing from this Guide may be found in the WY-99GT Programmer's Guide. The VT100 emulation (personality) is known as ANSI and uses ANSI key codes per p. A-10+ even though the keyboard may be ASCII. A sub-heading on p. A-13 "ASCII Keyboard" also pertains to VT100 because it has an "ANSI KEY ..." super-heading a few pages previously. But not all ASCII keyboard headings pertain to VT100 since they may fall under a non-ANSI personality super-heading which may found be a few pages previously. Appendix H is the "ANSI Command Guide" except for the VT52 (ANSI) personality which is found in Appendix G.

Wyse 150

When exiting set-up using F12, hitting space changes "no" to "yes" to save the set-up. The sentence to the left of this no/yes is about "vertical alignment" and has nothing to do with this no/yes for saving the set-up (confusing menu design).

Wyse 185

Has 10x20 character cells. Can emulate DEC VT320. Uses 45 watts power. Later models were 185e.

Low Emissions: -ES

ES after the model number means low emissions: low magnetic field, etc.

END OF Text-Terminal-HOWTO

Next Previous Contents Text-Terminal-HOWTO-2.html0000644000160500001440000001426412117203375014516 0ustar gfergusers Text-Terminal-HOWTO: Types of Terminals Next Previous Contents

2. Types of Terminals

2.1 Dumb Terminals

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.

2.2 Text Terminals

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 is an integer that usually represents a printable character. Bytes typed at the keyboard go to the host 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 coded commands and most real 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. Prior to about 2004, most new PCs had serial ports, but today (2009) almost no new PCs come with serial ports. 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 one presses the send key (or the like) 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.

2.3 Graphic GUI Capabilities of Text Terminals

While emulated text terminals don't display images, many real text terminals can display bit-mapped images, but not in color. Unfortunately, the popular image formats used on the Internet are not supported. Thus the display of images is seldom used. 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.

Graphics GUI displays

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).

Next Previous Contents Text-Terminal-HOWTO-3.html0000644000160500001440000003176012117203375014517 0ustar gfergusers Text-Terminal-HOWTO: Thin Clients Terminals Next Previous Contents

3. Thin Clients Terminals

3.1 Introduction

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 but (as of 2010) they are unfortunately not up to date. 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. 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".

Instead of "thin client" they could have been simply called "graphic terminals" but promoters of this technology wanted a catchy name to get customers to believe that it was perhaps a totally different technology. This trend of renaming what is basically just graphic terminals (with new features) continues unabated. Some of these names are "Virtual Desktop" and "Cloud Computing".

Thin clients may be created from an ordinary PC by using software or may be a stand-alone piece of hardware. But such stand-alone hardware may often be just a conventional PC monitor plus a small box for the computer part of the hardware. Linux seems to favor the use of PCs as clients.

Some claim that text-terminals are also a type of thin client 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 to access a PC. 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 (wireless and/or 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. Recent ones also have USB interfaces as well as ethernet.

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

3.2 MS Window terminals

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.

3.3 Network computers (NC's)

See Network Computer - Wikipedia which claims that NC's are defunct as a type of hardware, but that NC is used as a synonym for "thin client".

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.

3.4 Thin clients and NCs under Linux

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:

3.5 Hardware hookups

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 (no longer made ?) 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.

3.6 History and the future

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.

Next Previous Contents Text-Terminal-HOWTO-4.html0000644000160500001440000000563112117203375014516 0ustar gfergusers Text-Terminal-HOWTO: Quick Text-Terminal Install Next Previous Contents

4. Quick Text-Terminal Install

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.

Next Previous Contents Text-Terminal-HOWTO-5.html0000644000160500001440000002351612117203375014521 0ustar gfergusers Text-Terminal-HOWTO: Why Use a Terminal ? Next Previous Contents

5. Why Use a Terminal ?

5.1 Intro to Why Use a Terminal




5.2 Lower Hardware Costs ?





5.3 Control of Software


5.4 Hardware Upgrades


5.5 Other Advantages of Terminals

5.6 Major Disadvantages of Text Terminals

5.7 Major Disadvantages of All Terminals

5.8 Are Text Terminals Obsolete ?




Next Previous Contents Text-Terminal-HOWTO-6.html0000644000160500001440000002632712117203375014525 0ustar gfergusers Text-Terminal-HOWTO: Overview of How Text Terminals Work (in Linux) Next Previous Contents

6. Overview of How Text Terminals Work (in Linux)

See also section Some Details on How Terminals Work

6.1 Device Names

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".

6.2 Login/Logout

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 and/or console log in (after giving their passwords) and then have access to the computer. When it's time to shut the terminal down, everyone must log off and (and power off their terminal). See Login Restrictions regarding restricting logins (including allowing the root user to log in at terminal).

6.3 Half/Full Duplex

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 intentionally 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.

6.4 Terminal Memory

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.

6.5 Commands for the Terminal

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

6.6 Lack of Standardization Solved by Terminfo

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.

6.7 The Interface

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.

6.8 Emulation

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.

6.9 The Console

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.

Next Previous Contents Text-Terminal-HOWTO-7.html0000644000160500001440000002227712117203375014526 0ustar gfergusers Text-Terminal-HOWTO: Terminal Special Files such as /dev/tty Next Previous Contents

7. Terminal Special Files such as /dev/tty


7.1 Serial Port Terminals



7.2 Pseudo Terminals












7.3 The Controlling Terminal /dev/tty


7.4 /dev/ttyIN "Terminals"


7.5 The Console: ttyN or vc/N



7.6 Creating a Device with "mknod"


Next Previous Contents Text-Terminal-HOWTO-8.html0000644000160500001440000002033112117203375014514 0ustar gfergusers Text-Terminal-HOWTO: Some Details on How Terminals Work Next Previous Contents

8. Some Details on How Terminals Work


8.1 Terminal Memory Details



8.2 Early Terminals


8.3 Escape Sequences and Control Codes (intro)


Control codes


Escape sequences




8.4 Display Attributes & Magic Cookies




Next Previous Contents Text-Terminal-HOWTO-9.html0000644000160500001440000004600712117203375014525 0ustar gfergusers Text-Terminal-HOWTO: Special Features/Types of Some Terminals Next Previous Contents

9. Special Features/Types of Some Terminals

9.1 Terminal Uses a PC Monitor

One may use a PC (including it's monitor) to emulate a terminal. But PCs have become so powerful that only a small portion of the PC's capacity is utilized to run the emulation. So why not make a tiny PC that has low computing capability so it is barely able do the task of emulating a terminal. Then call this tiny device a text terminal and point out that one must supply and plug in a PC monitor in order to use this terminal. Such devices exist and are only about an inch high. They are sometimes referred to as small footprint terminals. Their advantage is that they are cheap, take up little space, and might be able to use surplus monitors that otherwise might be discarded.

9.2 Color

Emulated text terminals

In contrast to the monochrome or most real text terminals, an emulated text terminal usually has colors since it displays on a PC color monitor. See Colors on Emulated Terminals

Old real text terminal

Some real terminals had color displays but most had either no color or fixed "color" displays other than white such as green or amber. All terminals had 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.

Real color works like the color on a computer monitor or TV screen. The CRT has three colors of dots permanently on it with the brightness of each color controlled by its own electron beam (3 beams). The monochrome of real text terminals had inherently better resolution since it didn't depend on dots permanently fixed on the screen. For text terminals the only use of color is to differentiate text and this advantage was often not worth the cost of worse resolution. Thus monochrome may have historically been better since it also cost less. But today color displays have are ubiquitous and have improved in resolution since the olden days of the real text terminal.

9.3 Multiple Sessions

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".

9.4 Printer/Auxiliary Port

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.

9.5 Pages

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.

9.6 Character-Sets

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.

Graphics (Line Drawing, etc.)

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.

National Replacement Characters (obsolete)

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     --------

9.7 Fonts

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
For mapping the keyboard (and screen) for use of various fonts see Character Mapping: mapchan

9.8 Keyboards & Special Keys

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).

9.9 Mouse

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. An article for a mouse on VT terminals was once at http://www.cs.utk.edu/ shuford/terminal/dec_vt_mouse.html but it's now a dead link (2013). Try the "Wayback" machine." These escape codes for mice are called "DEC Locator sequences". The FALCO Infinity Series of terminals, model ANSI-G supports it. Did any linux applications support this ??

Next Previous Contents Text-Terminal-HOWTO.html0000644000160500001440000006012712117203376014357 0ustar gfergusers Text-Terminal-HOWTO Next Previous Contents


David S. Lawyer mailto:dave@lafn.org

v1.43 March 2013
This document was originally written for real text terminals which were like monitors (with keyboards), but could only display text with a command line interface (no pictures). They were widely used to access mainframe computers in the late 1970's and 1980's but use of them declined in the 1990's and they are seldom used anymore. However much of this howto also applies to command-line interfaces on Linux PC's which are in wide use today. It's not about the user programs one might run on the command line, but about setting up, managing, and understanding the interface itself Such as using a monitor as a virtual (text-only) console, using a text-window in a GUI such as xterm, connecting to a remote computer over a network via ssh, telnet, etc., or even using software on another PC to turn it into a serial-port text-terminal. All these 4 methods are known as "text-terminal emulation". But unfortunately, the main emphasis in this howto is real text terminals and the coverage of emulation is inadequate for the first 3 methods of emulation mentioned above. The Keyboard-and-Console-HOWTO filled much this gap but it was written for Linux 2.0 and now needs rewriting (or merging into this Text-Terminal howto). A new author is needed that has time to do all this. For the seldom used real text-terminals, it explains how they work, explains how to install and configure them, and provides some info on how to repair them. This HOWTO also provides a brief overview of modern GUI terminals.

1. Introduction

2. Types of Terminals

3. Thin Clients Terminals

4. Quick Text-Terminal Install

5. Why Use a Terminal ?

6. Overview of How Text Terminals Work (in Linux)

7. Terminal Special Files such as /dev/tty

8. Some Details on How Terminals Work

9. Special Features/Types of Some Terminals

10. Terminal Emulation (including the Console)

11. Flow Control (Handshaking)

12. Physical Connection

13. Set-Up (Configure) in General

14. Terminal Set-Up (Configure) Details

15. Computer Set-Up (Configure) Details

16. Terminfo and Termcap (detailed)

17. Using the Terminal

18. Special Uses for a Terminal

19. Trouble-Shooting

20. Repair & Diagnose

21. Appendix A: General

22. Appendix B: Escape Sequence Commands Terminology


24. Appendix D: Notes by Brand/Model

Next Previous Contents