42.1 Making Sense Out of the Terminal Mess

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

1. The shell, utility, or application that interprets and responds to what you type.

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

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

4. 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 layers. Let's take the list in the reverse order this time:

• Most ASCII terminals, or ttys, are connected to the system by a serial line-a set of up to 24 wires defined by the RS-232 standard. A 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. However, the stty command (41.2, 41.3) 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 terminals worked. 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 to different escape sequences (5.8) for moving the cursor around the screen, highlighting text in inverse video, underlining, and so on. The termcap and terminfo databases (5.2) were developed to make sense out of this babel. Once a terminal's characteristics are described in the database, a screen-oriented program like vi can look up the information it needs to clear the screen, move around, and so on. Programs like tset (5.11) and tput (5.12, 41.10) 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 (41.9). 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 of terminals.)

• 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 41.2. 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, and that stty (41.3) is the program that reports (and changes (5.9)) the settings.

  Not all of the terminal driver settings are obscure. Some of them you use every day, and must be sure to set in your .login or .profile file (2.3). 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 aren't interpreted. Have you ever typed CTRL-z when you're in vi's insert mode? Instead of vi being suspended, the character is input. That's because vi needs to reset the serial driver to a different mode (41.2) 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 quoting (8.14), 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 8.20 is about backslash handling.)

Are the terminal and computer system properly configured? Has the cable come loose? Is the 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?