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
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.
(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.ttyS
N or
/etc/conf.{uu}getty.ttyS
N), 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.
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
.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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
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.
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.
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.
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 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).
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.
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 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