Part of the set-up is setting up the physical terminal by saving (in its non-volatile memory) the characteristics it will have when it is powered on. In addition (or as an alternative), the terminal may be configured by sending escape sequences to it from the computer, but this configuration will usually be lost when the terminal is powered down. So if you know how to set up and save the configuration inside the terminal it's likely the best way.
Another part of the setup is letting the computer know what kind of terminal you have connected it to and how the terminal has been set up. The environment variable TERM stores the name of the terminal and makes it easy for programs to look up the terminal capabilities under this name in the terminfo directory. See Terminfo & Termcap (brief).
Programs called "stty" and "setserial" configure the serial port at the computer (including it's device driver software). These programs (if needed) must be run each time the computer starts up since the configuration is lost each time the computer powers down.
There are a great many options for you to choose from. 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?
The "communication interface" options must be set exactly the same at the computer and inside the terminal: speed, parity, bits/character, and flow control. Until these are compatibly set up there can be no satisfactory serial communication (and possibly no communication at all) between the terminal and the computer. One must set these by doing it manually at each terminal (or using some sort of special cartridge at each terminal). The host computer is configured by adding commands to certain files on its hard disk which will be executed each time the computer starts (or when people log in).
While all this 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 to make the display look better and perform better more work may be needed.
Once the communication interface is established, the rest of the configuration of the terminals may sometimes be done by sending commands 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.
If you have a manual for your terminal, you should also consult it. You may send commands to configure the terminal 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. Unless you plan to send these sequences 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.
To set up a terminal you usually need to enter set-up mode by depressing the "set-up" key (or the like). This will display a menu from which you may go to other menus. How to go to other menus may (or may not) be inferred from the display. 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. Older terminals may only have only one "set-up" menu. Still older ones have physical switches. In some cases not all the switches are well labeled. They may even be DIP switches hidden in obscure locations with no labels.
Unless you set up the terminal by throwing switches, 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. In some older terminals, only the manual tells how to save them.
(Of course you might do this from any working terminal connected to the computer.)
There are various files to edit to set up the computer for terminals. With luck, only one file on the computer needs to be changed: /etc/inittab. Add a new getty command(s) to this file next to the existing getty command(s). Getty will start a login process on the serial port(s) of your choice and tell the computer what kind of terminal you have via the TERM environment variable (see Serial-HOWTO 4.1 & 7.2 and/or type "man getty").
If you are not using modem control lines (for example if you only use the minimum number of 3 conductors: transmit, receive, and common signal ground) you must let getty know this by using a "local" flag. The format of this depends on which getty you use.
There is both a "stty" command and a "setserial" command for setting up the serial ports. Some (or all) of the needed stty settings can be done via getty and there may be no need to use setserial so you may not need to use either command. These two commands (stty and setserial) set up different aspects of the serial port. Stty does the most while setserial configures the low-level stuff such as interrupts and port addresses. To "save" the settings, these commands must be written in certain files (shell scripts) which run each time the computer starts up. You may also use the stty and setserial commands on the command line, but such settings will be lost as soon at you turn off the computer.
Setserial can change both the interrupt (IRQ) number and the port address. It can tell you what type of UART chips you have. It can set the time that the port will keep operating after it's closed (in order to output any characters still in its buffer in main RAM). This is needed at slow baud rates of 1200 or lower. For setserial to work, the serial module (for the Linux kernel) must be loaded. If you use more than 2 serial ports you need to use setserial to assign unique IRQ numbers.
To modify (or add) a setserial command, edit the shell script that runs setserial. Where it resides depends on your distribution. It might be in /etc/rc.d in a "rc.local" or "rc.serial" file. In the Debian distribution it was the 0setserial file in /etc/rc.boot but this eventually should change to a file in /etc/init.d.
Stty does most of the configuration of the serial port. To see how it's now set for the terminal (or console) you're now at type at the shell prompt: stty -a. For other terminals (such as ttyS1) type: stty -a < /dev/ttyS1. Here are some of the items stty configures: speed (bits/sec), parity, bits/byte, # of stop bits, strip 8th bit?, modem control signals, flow control, break signal, end-of-line markers, change case, padding, beep if buffer overrun?, echo, allow background tasks to write to terminal?, define special (control) characters (such as what keys to press for interrupt). See the manual (type: man stty) for more details. For use of some special characters see Special (Control) Characters
With some implementations of getty, the commands that one would normally give to stty are typed into a getty configuration file: /etc/gettydefs. Even without this configuration file, the getty command line may be sufficient to set things up so that you don't need stty.
One may write C programs which change the stty configuration, etc. Looking at the documentation for this may help one better understand the use of the stty command (and its many possible arguments). Serial-Programming-HOWTO is useful. The manual page: termios contains a description of the C-language structure (of type termios) which stores the stty configuration in computer memory. Many of the flag names in this C-structure are almost the same (and do the same thing) as the arguments to the stty command.
To have stty set up the terminal each time the computer starts up you need to put the stty command in a file that will be executed each time the computer is started up (Linux booted). This file should be run before getty starts. There are many possible places to put it. If it gets put in more than one place and you only know about (or remember) one of those places, then a conflict is likely. So make sure to document (perhaps in your terminal manual) where it's put.
One good place to put it would be in the same file that runs setserial when the system is booted. See Where to Run Setserial?. It would seem best to put it after the setserial command so that the low level stuff is done first. In the Debian distribution there is an /etc/init.d/bootmisc.sh script but it currently runs before 0setserial does. Example line: stty crtscts < /dev/ttyS1.
See Terminfo and Termcap (detailed) for a more detailed discussion of termcap. Many application programs that you run use the terminfo (formerly termcap) data base. This has an entry for each model or type (such as vt100) of terminal and tells what the terminal can do, what codes to send for various actions, and what codes to send to the terminal to initialize it.
Since many terminals (and PC's also) can emulate other terminals and have various "modes" of operation, there may be several terminfo entries from which to choose for a given physical terminal. They usually will have similar names. The last parameter of getty should be the terminfo name of the terminal (or terminal emulation) that you are using (such as vt100).
The terminfo does more than just specify what the terminal is capable of doing and disclose what codes to send to the terminal to get it to do those things. It also specifies what "bold" will look like, what the cursor will look like, if the letters will be black, white, or some other color, etc. In PC terminology these are called "preferences". It also specifies initialization codes to send to the terminal (analogous to the init strings sent to modems). If you don't like the way the display on the screen looks and behaves you may need to edit (and then install) the terminfo (or termcap) file.
These settings are:
The above settings must be set the same at both the terminal and computer. At the computer these may often set by using parameters to the getty command in the /etc/inittab file. All of them may be set at the computer with the "stty" command which you might put in a shell script. The script must be run each time the computer starts up. You could put the stty command in an existing script file which is run at boot-time. See Where to Put the Stty Command ?
These must be set the same on both the terminal and the computer. The speed is the bits/sec (bps or baud rate). 9,600 is often fast enough, but if a faster speed improves performance without errors, use it. 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. Common speeds are 300, 600, 1200, 2400, 4800, 9600, 19200, ... An old terminal may even have a speed of 2 to be compatible with teletypes of the 1920's that formed serial bytes by mechanical means without electronics.
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 which one you choose. 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.
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 correcting spelling errors that don't really exist. However parity comes at a cost. First, it's a little 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.
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 ever 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). For ASCII it's 7, but it's 8 for ISO 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 older terminals will only display 7-bit characters.
The choice is between "hardware" (for example rts/cts + dtr/dsr) or "software" (Xon/Xoff) flow control. While hardware may be faster (if the 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 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.
The configuration file /etc/ttytype is used to map /dev/ttySn's to terminal names per terminfo. tset uses it, but if the TERM environment variable is already set correctly, then this file is not needed. Since the Linux getty sets TERM for each tty, you don't need this file. In other Unix-like systems such as FreeBSD, the file /etc/ttys maps ttys to much more, such as the appropriate getty command, and the category of connection (such as "dialup"). An example line of Linux ttytype: vt220 ttyS1
By default, the root user may not login from a terminal. To permit this you must create (or edit) the file /etc/securetty per the manual page "securetty". To restrict logins of certain users and/or certain terminals, etc. edit /etc/login.access (this replaces the old /etc/usertty file ??). /etc/login.def determines if /etc/securetty is to be used and could be edited so as to make /etc/securetty not needed (or not used). /etc/porttime restricts the times at which certain ttys and users may use the computer. If there are too many failed login attempt by a user, that user may be prohibited from ever logging in again. See the man page "faillog" for how to control this.
Sometimes there are commands that one wants to execute at start-up only for a certain type of terminal. To do this for the stty command is no problem since one uses the redirection operator < to specify which terminal the command is for. But what about shell aliases or functions? You may want to make a function for the ls command so it will color-code the listing of directories only on color terminals or consoles. For monochrome terminals you want the same function name (but a different function body) which will use symbols as a substitute for color-coding. Where to put such function definitions that are to be different for different terminal?
You may put them inside an "if" statement in /etc/profile which runs at startup each time one logs on. The conditional "if" statement defines certain functions, etc. only if the terminal is of a specified type. While much of what this if statement does could be done in the configuration file for dircolors, here's an example:
if [ $TERM = linux ]; then
eval `dircolors`;
elif [ $TERM = vt220 ]; then
ls () { command ls -F $* }
declare -xf ls
else echo "From /etc/profile: Unknown terminal type $TERM"
fi