Next Previous Contents

14. Computer Set-Up (Configure) Details

There are various files to edit to set up the computer for terminals. If you're lucky, you'll only need to edit /etc/inittab. One does this by editing at the console (or from any working terminal).

14.1 Getty (in /etc/inittab)

In order to have a login process run on a serial port when the computer starts up (or switches run levels) a getty command must be put into the /etc/inittab file. Getty GETs a TTY (a terminal) going. Each terminal needs its own getty command. There is also at least one getty command for the console in every /etc/inittab file. Find this and put the getty commands for the real terminals next to it. This file may contain sample getty lines for text terminals that are commented out so that all you need to do is to uncomment them (remove the leading #) and change a few arguments.

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

  1. agetty (sometimes just called getty): Very easy to set up. No config files. See Agetty
  2. See getty (part of getty_ps)
Two gettys best for modems (avoid for terminals) are:
  1. mgetty: the best one for modems; works for terminals too but inferior
  2. uugetty: for modems only; part of the getty_ps package
A simple getty to use only for console login is:
  1. mingetty: for consoles only

If you don't have the getty you want check other distributions and the alien program to convert between RPM and Debian packages. The source code may be downloaded from Serial Software.

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 should let getty know this by using a "local" flag. The format of this depends on which getty you use.

Agetty (may be named getty)

An example line in /etc/inittab:

S1:23:respawn:/sbin/getty -L 19200 ttyS1 vt102
S1 is from ttyS1. 23 means that getty is run upon entering run levels 2 or 3. respawn means that if getty is killed, it will automatically start up (respawn) again. /sbin/getty is the getty command. The -L means Local (ignore modem control signals). -h (not shown in the example) enables hardware flow control (same as stty crtscts). 19200 is the baud rate. ttyS1 means /dev/ttyS1 (COM2 in MS-DOS). vt102 is the type of terminal and this getty will set the environment variable TERM to this value. There are no configuration files. Type "init q" on the command line after editing getty and you should see a login prompt.

The agetty program will auto-detect any parity set inside the terminal. If you use stty to set parity, agetty will automatically unset it since it wants the parity bit to come thru as if it was a data bit. This is because it needs to get the last bit (possibly a parity bit) as you type your login-name so that it can auto-detect parity. Thus if you use parity, enable it only at the terminals and let agetty auto-detect it and set it at the computer. If your terminal supports received parity, the login prompt will look garbled until you type something so that getty can detect the parity. The garbled prompt will deter visitors, etc. from trying to login. That could be just what you want.

There is sometimes a problem with this garbled prompt if you don't have the terminal powered on when getty starts to run. The agetty program detects the parity OK but if the first login attempt fails then the login program is run. This login program can't detect parity. Normally, parity has already been detected so all is OK. But if the terminal was off, login may fail without you typing anything. It seems that you can't login, but if you keep slowly pressing the return key then eventually the login prompt will be supplied by agetty again and you may finally login. For terminals that only support transmitted parity, you will not see any garbling but you will not be able to login until the agetty supplies the login prompt.

getty (part of getty_ps)

(This is from the old Serial-HOWTO by Greg Hankins)
Add entries for getty to use for your terminal in the configuration file /etc/gettydefs if there they aren't already there:

# 38400 bps Dumb Terminal entry
DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400

# 19200 bps Dumb Terminal entry
DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200

# 9600 bps Dumb Terminal entry
DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600

If you want, you can make getty print interesting things in the login banner. In my examples, I have the system name and the serial line printed. You can add other things:

@B    The current (evaluated at the time the @B is seen) bps rate.
@D    The current date, in MM/DD/YY.
@L    The serial line to which getty is attached.
@S    The system name.
@T    The current time, in HH:MM:SS (24-hour).
@U    The number of currently signed-on users.  This is  a
      count of the number of entries in the /etc/utmp file
      that have a non-null ut_name field.
@V    The value of VERSION, as given in the defaults file.
To display a single '@' character, use either '\@' or '@@'.

When you are done editing /etc/gettydefs, you can verify that the syntax is correct by doing:

linux# getty -c /etc/gettydefs

Make sure there is no getty or uugetty config file for the serial port that your terminal is attached to (/etc/default/{uu}getty.ttySN or /etc/conf.{uu}getty.ttySN), as this will probably interfere with running getty on a terminal. Remove the file if it exits.

Edit your /etc/inittab file to run getty on the serial port (substituting in the correct information for your environment - port, speed, and default terminal type):

S1:23:respawn:/sbin/getty ttyS1 DT9600 vt100
Restart init:
linux# init q 

At this point, you should see a login prompt on your terminal. You may have to hit return to get the terminal's attention.

mgetty

The "m" stands for modem. This program is primarily for modems and as of mid 1999 doesn't always work very well for text-terminals. It's poorly documented for terminals and you may need to wade thru much documentation for modems in order to figure out how to use it for terminals. Look at the last lines of /etc/mgetty/mgetty.config for an example of configuring it for a terminal. It will only support software (Xon/Xoff) flow control (used by many terminals) if you recompile it. This will be hopefully be fixed in the future. It would be nice to use the same getty for terminals as for modems but mgetty needs a little fixing to fill the bill.

14.2 Stty & Setserial

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. Distributions of Linux often supply a shell script which runs setserial but seldom supply one which runs stty.

14.3 Setserial

Introduction

Don't ever use setserial with Laptops (PCMCIA). setserial is a program which allows you to tell the device driver software the I/O address of the serial port, which interrupt (IRQ) is set in the port's hardware, what type of UART you have, etc. It can also show how the driver is currently set. In addition, it can probe the hardware (if certain options are given). Besides the manual for setserial, check out info in /usr/doc/setserial.../ or the like. It should tell you how setserial is handled in your distribution of Linux.

Setserial is often run automatically at boot-time by a start-up shell-script. It will only work if the serial module is loaded. If you should for some reason unload the serial module later on, the changes previously made by setserial will be forgotten. So setserial must be run again to reestablish them. In addition to running via a start-up script, something akin to setserial runs when the serial module is loaded. Thus when you watch the start-up messages on the screen it may look like it ran twice, and in fact it has.

m4_define TorS

If your serial port is Plug-and-Play you may need to consult other HOWTOs such as Plug-and-Play or Serial.

With appropriate options, setserial can probe (at a given I/O address) for a serial port but you must guess the I/O address. If you ask it to probe for /dev/ttyS2 for example, it will only probe at the address it thinks ttyS2 is at. If you tell setserial that ttyS2 is at a different address, then it will probe at that address, etc. See Probing

Setserial does not set either IRQ's nor I/O addresses in the serial port hardware itself. You must tell setserial the identical values that have been set in the hardware. It's set in the hardware either by jumpers or by plug-and-play. Do not just invent some values that you think would be nice to use and tell them to setserial. However, if you know the I/O address but don't know the IRQ you may command setserial to attempt to determine the IRQ.

You can see a list of possible commands to use (but not the one-letter options such as -v for verbose --which you should normally use when troubleshooting) by just typing setserial with no arguments. Note that setserial calls an I/O address a "port". If you type:

setserial-g /dev/ttyS*
you'll see some info about how that device driver is configured for your ports. Add a "v" to the option "-g" to see more. But this doesn't tell you if the hardware actually has these values set in it. If fact, you can run setserial and assign a purely fictitious I/O address, any IRQ, and whatever uart type you would like to have. Then the next time you type "setserial ..." it will display these bogus values without complaint. Note that assignments made by setserial are lost when the PC is powered down so it is usually run automatically somewhere each time that Linux is booted.

Probing

In order to try to find out if you have a certain piece of serial hardware you must first know (or guess) its I/O address (or the device driver must have an I/O address for it, likely previously set by setserial). To try to detect the physical hardware use the -v (verbose) and autoconfig command to setserial. If the resulting message shows a uart type such as 16550A, then you're OK. If instead it shows "unknown" for the uart type, then there is likely no serial port at all at that I/O address. Some cheap serial ports don't identify themselves correctly so if you see "unknown" you still might have something there.

Besides auto-probing for uart type, setserial can auto-probe for IRQ's but this doesn't always work right either. In versions of setserial >= 2.15, your last probe test may be saved and put into the configuration file /etc/serial.conf which will be used next time you start Linux. The script that runs setserial at boot-time does not usually probe, but you could change it so that it does. See the next section.

Can Linux Configure The Serial Devices Automagically?

Yes, but ... You may set Linux up to detect and set up the serial devices automatically on startup (probing). It's easy to do for setserial < 2.15. Just add some lines to the file that runs setserial on start-up. See Old configuration method: edit a script For example, for ttyS3 you would add:

/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
to the file that runs setserial on startup. Do this for every serial port you want to auto configure. Be sure to give a device name that really does exist on your machine.

For versions >= 2.15 (provided your distribution implemented the change, Redhat didn't) it's much harder to do since the file that runs setserial on startup, /etc/init.d/setserial or the like was not intended to be edited by the user. There may be no helpful comments in it like there were in earlier versions.

Boot-time Configuration

When the kernel loads the serial module (or if the "module" is built into the kernel) then only ttyS{0-3} are auto-detected and the driver is set to IRQs 4 and 3 (regardless of what the hardware is actually set at). You see this as a boot-time message just like as if setserial had been run.. If you use 3 or more ports, this may result in IRQ conflicts.

To fix such conflicts by telling setserial the true IRQs (or for other reasons) there may be a file somewhere that runs setserial again. This happens early at boot-time before any process uses the serial port. In fact, your distribution may have set things up so that the setserial program runs automatically from a start-up script at boot-time. More info about how to handle this situation should be found in /usr/doc/setserial.../ or the like.

New configuration method using /etc/serial.conf

Starting with version 2.15 (1999) of setserial the shell-script that runs from a file at boot-time gets its data from a configuration file: /etc/serial.conf. But serial.conf is normally never edited. Instead just use setserial on the command line. Normally, what you changed with the setserial command is saved to the configuration file (serial.conf) when you shutdown (normally) or reboot. This only works if "###AUTOSAVE### or the like is on the first line of serial.conf. If you should use setserial experimentally and it doesn't work out right, then don't forget to redo it so that the experimental settings don't get saved by mistake. The file most commonly used to run setserial at boot-time (in conformance with the configuration file) is now /etc/init.d/setserial (Debian) or /etc/init.d/serial (Redhat), or etc., but it also should not normally be edited.

To disable a port, use setserial to set it to "uart none". The format of /etc/serial.conf appears to be just like that of the parameters placed after "setserial" on the command line with one line for each port. If you don't use autosave, you may edit /etc/serial.conf manually. For 2.15, the Debian distribution installs the system with autosave enabled, but Redhat 6.0 just had a file /usr/doc/setserial-2.15/rc.serial which you have to move to /etc/init.d/.

BUG: As of July 1999 there is a bug/problem since with ###AUTOSAVE### only the setserial parameters displayed by "setserial -G /dev/ttyS?" (where ? = 0, 1, 2, ...) get saved but the other parameters don't get saved. This will only affect a small minority of users since the parameters not saved are seldom used anyway. It's been reported as a bug and may be fixed by now.

In order to force the current settings set by setserial to be saved to the configuration file (serial.conf) without shutting down, do what normally happens when you shutdown: Run the shell-script /etc/init.d/{set}serial stop. The "stop" command will save the current configuration but the serial ports still keep working OK.

Old configuration method: edit a script

Prior to 2.15 (1999), or if your distribution chose not to use /etc/serial.conf then you need to look for a file that runs setserial at boot-time. If it doesn't exist, you need to create one (or place the commands in a file that runs early at boot-time). If such a file is currently being used it's likely somewhere in the /etc directory-tree. But Redhat has supplied it in /usr/doc/setserial/ although you need to move it to the /etc tree before using it. You might use "locate" to try to find such a file. For example, you could type: locate "*serial*".

What you are looking for could be named rc.serial, or 0setserial (Debian). If such a file is supplied, it should contain a number of commented-out examples. By uncommenting some of these and/or modifying them, you should be able to set things up correctly. Make sure that you are using a valid path for setserial, and a valid device name. You could do a test by executing this file manually (just type its name as the super-user) to see if it works right. Testing like this is a lot faster than doing repeated reboots to get it right. Of course you can also test a single setserial command by just typing it on the command line.

The script /etc/rc.d/rc.serial was commonly used in the past. The Debian distribution used /etc/rc.boot/0setserial. Another file once used is /etc/rc.d/rc.local but it's not a good idea to use this since it may not be run early enough. It's been reported that other processes may try to open the serial port before rc.local runs resulting in serial communication failure.

IRQs

By default, both ttyS0 and ttyS2 share IRQ 4, while ttyS0 and ttyS3 share IRQ 3. But sharing serial interrupts is not permitted unless you: 1. have kernel 2.2 or better, and 2. you've complied in support for this, and 3. your serial hardware supports it. See Serial-HOWTO: Interrupt sharing and Kernels 2.2+.

If you only have two serial ports, ttyS0 and ttyS1, you're still OK since IRQ sharing conflicts don't exist for non-existent devices.

If you add an internal modem and retain ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set it both on your serial port (or modem card) and then use setserial to assign it to your device driver. If IRQ 5 is not being used for a sound card, this may be one you can use for a modem. To set the IRQ in hardware you may need to use isapnp, a PnP BIOS, or patch Linux to make it PnP. To help you determine which spare IRQ's you might have, type "man setserial" and search for say: "IRQ 11".

------------------------From TT-HOWTO-------------------------------------------

Setserial tells the serial port driver both the interrupt (IRQ) number and the port IO address. It can tell you what type of UART chips you have if you use the autoconfig parameter. For the serial port to work, the serial module (for the Linux kernel) must be loaded. If you use more than 2 serial ports and want to assign unique IRQ numbers (or use more than 4 serial ports), then you need to use setserial. If your serial port is plug-and-play you should look in the Serial-HOWTO. In addition to the man page for it, but sure to look at /usr/doc/setserial/ if it exists. It may tell you how setserial is run automatically at boot time and how to alter the configuration. Don't ever use setserial with Laptops (PCMCIA bus).

starting with version 2.15 (1999) of setserial changes made to setserial on the command line are sometimes automatically saved so that they will remain after you shut off the computer.

Where to Run Setserial ?

Starting with version 2.15 of setserial the method of configuration changed. Before 2.15 you configured it by editing a shell-script that ran setserial. After 2.15 there's a configuration file /etc/serial.conf which is automatically edited to conform with whatever you do with the setserial command.

You may find you have both the old and new way of configuring installed. If the shell-script is named "...pre-2.15" or the like, it's probably not being used anymore so everything should be OK if you keep it.

Prior to version 2.15

Prior to 2.15 there was no configuration file for setserial. One needs to edit the shell-script that runs setserial at boot-time. You need to find it or create one if it doesn't exist. Where it is depends on your distribution. It might be in a file named "rc.serial" . In the Debian distribution it was the 0setserial file in /etc/rc.boot. One way to try to find it is to search for it with the "locate" command.

Version 2.15 and later

You neither edit the file that runs setserial nor the configuration file. Changes made by using setserial on the command line are *sometimes* saved in /etc/serial.conf during normal shutdown. This feature is called autosave. It only works if the first line of serial.conf contains ###AUTOSAVE### or the like.

There's a bug I've reported in 2.15 and it's been fixed (but you could still have it): With the bug, seldom used changes made by setserial don't get saved. Only the most important parameters that you see if you give the command "setserial -g /dev/ttyS?" do get saved.

If autosave is enabled, then each time you boot, setserial is run by /etc/init.d/setserial (or "serial", etc.) using the saved configuration.

14.4 Stty

Introduction

stty does much of the configuration of the serial port but since application programs (and the getty program) often handle it, you may not need to use it much. It's handy if your having problems or want to see how the port is set up. 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. Don't try to learn all the setting unless you want to become a serial guru. Most of the defaults should work OK and some of the settings are needed only for certain obsolete dumb terminals made in the 1970's. Dumb terminals made after about 1980 don't use them.

Whereas setserial only deals with actual serial ports, stty is used both for serial ports and for virtual terminals such as the standard Linux text interface at a PC monitor. For the PC monitor, many of the stty settings are meaningless. Changing the baud rate, etc. doesn't appear to actually do anything.

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 key to press for interrupt). See the stty man or info page for more details. Also see the man page: termios which covers the same options set by stty but (as of mid 1999) covers features which the stty man page fails to mention. For use of some special characters see Special (Control) Characters

With some implementations of getty (getty_ps package), 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 some of 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.

Using stty for another port

Using stty to inspect or configure another terminal or serial port is tricky. For example, let's say you are at the PC monitor (tty1) and want to use stty for the serial port ttyS2. You need to use the redirection operator <. First, be warned that if there is a terminal on ttyS2 and a shell running on that terminal, then what you see will likely be deceptive and trying to set it will not work. See Two Interfaces at a Terminal to understand it.

Type ``stty -a < /dev/ttyS2'' to look at the settings of ttyS2. Use the same redirection operator < to set ttyS2. Some people try to use ``stty ... > /dev/ttyS2 to set the terminal. This will not do it. Instead, it takes the message normal displayed by the stty command for the terminal you are on (tty1) and sends this message to ttyS2 but it doesn't change any settings for ttyS2.

Versions starting with 1.17 (still not released as of mid 1999) will no longer need to use redirection (<) but instead will use ``stty ... -F /dev/ttyS2'' (or --file instead of F) etc.

Two interfaces at a terminal

When using a shell (such as bash) with command-line-editing enabled there are two different terminal interfaces (what you see when you type stty -a). When you type at the command line you have a temporary "raw" interface (or raw mode) where each character is read by the 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 to the nominal "cooked" interface (cooked mode) for the terminal. This "cooked" mode lasts until the next prompt is sent to the terminal. Note that one never types anything to this "cooked" mode but it does have a purpose.

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 since you are starting the command-line editor). The settings for the "raw" mode are based only on the basic 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. Thus if one uses stty to change settings for the raw mode, such settings will be lost as soon as one hits the <return> key at the terminal that has supposedly been "set".

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 another terminal to deal with a terminal that is displaying a command line, then the view is that of the raw mode. Any changes made will only be made to the raw mode and will be lost when someone presses <return> at the terminal you tried to "set". But if you type a stty command at your terminal (without using < for redirection) and then hit <return> it's a different story. The <return> puts the terminal in cooked mode. Your changes are saved and will still be there when the terminal goes back into raw mode (unless of course it's a setting not allowed in raw mode).

This situation can create problems. For example, suppose you corrupt your terminal interface and to restore it you go to another terminal and "stty sane <dev/ttyS1" to restore it. It will not work! 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. Luckily, a file that runs stty at boot-time will likely deal with a terminal (or serial port with no terminal) that has no shell running on it so there's no problem.

Where to put the stty command ?

Should you need to have stty set up the serial interface each time the computer starts up then you need to put the stty command in a file that will be executed each time the computer is started up (Linux boots). It should be run before the serial port is used (including running getty on the port). 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 what you do.

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.

14.5 Terminfo & Termcap (brief)

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 (or file) 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 (for both agetty and getty_ps) 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 (will it be reverse video or will it be high intensity, etc.), 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). Such strings are not automatically sent to the terminal by Linux. See Init String. If you don't like the way the display on the screen looks and behaves you may need to edit (and then update) the terminfo (or termcap) file. See Terminfo Compiler (tic) for how to update.

14.6 Setting TERM and TERMINFO

These are two environment variables for terminals: TERM and TERMINFO, but you may not need to do anything about them. TERM must always be set to the name of the terminal you are using. If you don't know the name see What is the terminfo name of my terminal ?. TERMINFO contains the path to the terminfo data base, but may not be needed if the database is in a default location (or TERMINFO could be set automatically by a file that comes with your distribution of Linux). You may want to look at Where is the compiled database located ?.

Fortunately, the getty program usually sets TERM for you just before login. This permits application programs to find the name of your terminal and then look up the terminal capabilities in the terminfo data base. See TERM Variable for more details on TERM.

If your terminfo data base can't be found you may see an error message about it on your terminal. If this happens it's time to check out where terminfo resides and set TERMINFO if needed. You may find out where the terminfo database is by searching for a common terminfo file such as "vt100" using the "locate" command. Make sure that your terminal is in this database. An example of setting TERMINFO is: export TERMINFO=/usr/share/terminfo (put this in /etc/profile or the like). If the data for your terminal in this data base is not to your liking, you may need to edit it. See Terminfo & Termcap (brief).

What is the terminfo name of my terminal ?

You need the exact name in order to set the TERM environment variable or to give to getty. The same name should be used by both the termcap and terminfo databases so you only need to find it once. A terminal usually has alias names but if more than one name is shown, use the first one.

To find it, try looking at the /etc/termcap... file (if you have it). If not, then either look at the terminfo trees (see Where is the compiled database located ?) or try to find the terminfo source code file (see Source code database locations.

14.7 Rarely Needed /etc/ttytype File

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

14.8 Login Restrictions

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.

14.9 Run Command Only If TERM=my_term_type

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

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.

Example for ls Function

While much of what this if statement does could be done in the configuration file for dircolors, here's an example for the case of the bash shell:


if [ $TERM = linux ]; then
    eval `dircolors`;
elif [ $TERM = vt220 ]; then
    ls () { command ls -F $* ; }# to export the function ls():
    declare -xf ls
else echo "From /etc/profile: Unknown terminal type $TERM"
fi


Next Previous Contents