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).
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:
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.
An example line in /etc/inittab:
S1:23:respawn:/sbin/getty -L 19200 ttyS1 vt102
The agetty program will auto-detect any parity set inside the
terminal. Except it will not work if you use 8-bit data bytes with
1-bit parity. See
Agetty's parity with 8-bit data bytes. 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 auto detection of parity. This
happens because after you first type your login name, agetty uses
the login program to finish logging you in. If the first login
attempt fails, login runs again to handle all future attempts at
logging in (including the type-in of your login-name). The problem is
that only agetty can detect parity while the login program
doesn't detect parity. So if for some reason you wind up in the
login program and the correct parity hasn't yet been detected,
you're in trouble since the login program can't detect the
parity. With wrong parity, the login program can't correctly
read what you type and you can't log in. If your terminal supports
received parity, you will continue to see a garbled screen.
One may get into this "login loop" in various ways. Suppose you only type a single letter or two for your login name and then hit return. If these letters are not sufficient for parity detection, then login runs before parity has been detected. Sometimes this problem happens if you don't have the terminal on and connected when agetty first starts up. If you get stuck in this "login" loop a solution is to just wait about a minute until agetty runs again due to "timeout".
Unfortunately, agetty can't detect this parity. It (as of late 1999) has no option for disabling the auto-detection of parity and thus will detect incorrect parity. The result is that the login process will be garbled and parity will be set wrong. Thus it doesn't seem feasible to try to use 8-bit data bytes with parity.
(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
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.
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.
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 since on seldom need it.
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).
If you only have one or two serial ports, they will usually get set up
correctly without using setserial. Otherwise (or if there are
problems with the serial port) you will likely need to deal with
setserial. 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 by the
kernel (but not by /etc/serial.conf). 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.
Setserial 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. It's also needed at higher speeds if there are a lot of "flow control" waits. 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. It's set in the hardware either by jumpers or by plug-and-play. You must tell setserial these identical values that have been set in the hardware. Do not just invent some values that you think would be nice to use and then 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.
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 supposedly 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 a serial port 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.
Yes, but ... Your distribution may already do this on startup. But you may want to customize it. 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
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
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.
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.
Prior to setserial version 2.15, the way to configure setserial
was to manually edit the shell-script that ran setserial at boot-time.
Starting with version 2.15 (1999) of setserial this shell-script
is not edited but instead gets its data from a configuration file:
/etc/serial.conf. Furthermore not even serial.conf is intended to be
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.
I some cases you may wind up with both the old and new configuration methods installed but hopefully only one of them runs at boot-time. Debian labeled obsolete files with "...pre-2.15".
Prior to 2.15 (1999) there was no /etc/serial.conf file to configure setserial. Thus you need to find the file that runs "setserial" at boot time and edit it. 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 <6.0 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.
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".
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 (but not much after that)
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 to inspect or configure the terminal that you are
currently using is easy. Doing it for a different (foreign) 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. This makes ttyS2 the standard input to stty. This gives the stty program a link to the "file" ttyS2 so that it may "read" it. But instead of reading the bytes sent to ttyS2 as one might expect, it uses the link to find the configuration settings of the port so that it may read or change them. 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 (say tty1) and sends this message to ttyS2. But it doesn't change any settings for ttyS2.
Here's another problem with the redirection operator. Sometimes when trying to use stty, the command hangs and nothing happens (you don't get a prompt for a next command even after hitting <return>). This is likely due to the port being stuck because it's waiting for one of the modem control lines to be asserted. For example, unless you've set "clocal" to ignore modem control lines, then if no CD signal is asserted the port will not open and stty will not work for it. A similar situation seems to exist for hardware flow control. If the cable for the port doesn't even have a conductor for the pin that needs to be asserted then there is no easy way to stop the hang.
One way to try to get out of the above hang is to use a program on the port that will force it to operate even if the control lines say not to. Then hopefully this program might set the port so it doesn't need the control signal in the future in order to open: clocal or -crtscts. To use "minicom" to do this you have to reconfigure minicom for another ttyS, etc, and then exit it and restart it. Since you then have to reconfigure minicom again, it may be simpler to just reboot the PC.
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. This should force the port to open and avoid the 2nd problem with redirection.
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 what was typed in raw mode becomes cooked mode as soon as one hits the <return> key.
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.
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 place to put it would be in the same file that runs setserial when the system is booted. The location is distribution and version dependent. It would seem best to put it after the setserial command so that the low level stuff is done first. If you have directories in the /etc tree where every file in them is executed at boot-time (System V Init) then you could create a file named "stty" for this purpose.
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.
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 type of the terminal you are using (such as vt100). If you don't know the type (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 Compiled database locations.
Fortunately, the getty program usually sets TERM for you just before login. It just uses the terminal type that was specified on getty's command line (in /etc/inittab). 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).
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 Compiled database locations) or try to find the terminfo source code file (see Source-code database locations.
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". But use of this may be be distribution specific as the Suse distribution doesn't use /etc/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 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.
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