When you're sitting in front of a terminal, it's sometimes hard to
realize that you're face to face with about twenty-five years of
accumulated history, with hack piled upon hack to deal with
evolutions in hardware.
When you type at a terminal, you are really dealing with four
The shell, utility, or application
that interprets and responds to what you type.
The UNIX kernel, or more specifically, the serial line driver,
which may perform some low-level conversions on what you type
before it's even passed to the program you think you're talking to.
The terminal, which has behavior of its own - and may locally interpret
or respond to some of what you type instead of, or as well as,
passing it through to the system.
The communication link between the terminal and the system.
Some of the confusion about UNIX terminal handling comes from the
fact that there are mechanisms for dealing with each of these
Let's take the list in the reverse order this time:
Most ASCII terminals, or
s, are connected to the system by a
-a set of up to 24 wires defined by the RS-232 standard.
remote terminal may be connected to a modem by a serial line; if this
is the case, the computer too must be connected to a modem, and the
two modems talk to each other over the telephone.
Some serial line
configuration happens at the hardware level.
For example, not every
cable includes every wire called for in the RS-232 standard, and both
the terminal and the system or modem have to agree to such things as which
one will talk over which wire.
(Actually, both computer systems and
terminals are quite stubborn about this; they have fixed ideas about
which wire to talk on, and which to listen on, and if both want to
use the same one, it's up to the system administrator to trick them
by crossing the wires.)
There's more to the communications link than just the wires, though.
For example, both the terminal and the system or modem have to be
configured to agree on such things as how many data bits make up a
character (a byte is made up of eight bits, but ASCII characters only
require seven), whether or not to use parity (a simple form of error
checking), how to "frame" each character with "start" and "stop"
bits, and how fast to communicate (the baud rate).
All of these things are usually configured in advance - if they
weren't, the system and terminal couldn't talk to each other.
does let you change these parameters on the fly (at least on the system
side - your terminal may have a setup key and a built-in setup menu).
You'd better know what you're doing, though, or you may render your terminal
and computer unable to communicate.
At least when UNIX started out, there were no standards for how
A screen size of 24 lines and 80 columns became a
(fairly) common denominator, but the special keys on terminal keyboards
generate different characters, and each terminal might respond
escape sequences (
for moving the cursor around the screen, highlighting text in inverse
video, underlining, and so on.
were developed to make sense out of this babel.
Once a terminal's
characteristics are described in the database, a screen-oriented
can look up the information it needs to clear
the screen, move around, and so on.
were created to read the terminal database and use the information it
contains to issue commands (in the form of escape sequences) to the terminal.
If you always use the same kind of terminal, you can
configure your terminal by
issuing the escape sequences directly (
You don't need to look them up in the terminal database.
(That's only important if you want a program or script to work with a variety
The serial line driver does various things to the characters it gets
from the terminal.
For example, in normal use, it changes the carriage return
(ASCII character \015) generated by the RETURN key on your keyboard
into a linefeed (ASCII character \012).
Chris Torek talks about
some of these conversions in article
For the most part, unless you are a programmer or a system
administrator, you don't need to know a whole lot about all of the
possibilities - but you do need to know that they are configurable,
is the program that reports (and
Not all of the terminal driver settings are obscure.
Some of them
you use every day, and
must be sure to set in your
For example, how does the system know that
you want to use CTRL-c to interrupt a program or CTRL-s to stop
output, or CTRL-z to suspend execution?
This happens at a level
below even the shell - the shell never even sees these characters,
because they are interpreted and acted on by the serial line driver.
However, there are times when they
you ever typed CTRL-z when you're in
's insert mode?
being suspended, the character is input.
reset the serial driver to a different mode (
so that it has control over which characters are echoed and which are
interpreted as commands.
All of this is by way of saying that there's an awful lot of
complexity under the skin.
And, of course, as we've talked about at length in the discussion
of wildcards and
the shell may intercept and act on various characters before passing
them on to another program.
The point of this long excursion is to suggest that when you are
trying to figure out problems with terminals, you owe it to
yourself to know about all the levels where the problems can occur.
(For example, article
is about backslash handling.)
Are the terminal and computer system properly configured?
Has the cable come loose?
terminal type set correctly so that programs know how to make that
particular terminal do their bidding?
Has an interrupted program
sent out unfinished commands that left the terminal in an
inconsistent or unusual state?
Is it really a terminal problem, or
is it just that things aren't working quite the way you expect?