This section is about controlling the terminal-computer interface and/or changing the terminal set-up while using the terminal. It explains (or points to explanations of) how the user of a terminal can control and inspect the interface and how to use various commands provided by the device driver. It does not explain how to use the many application programs, shells or most Linux utilities. Two commands commonly used at the terminal are:
Of course the power must be on for the terminal to work. If you don't see a login prompt hit the "return" (or "enter") key a few times. Then type your account name (followed by a return/enter) and your password when prompted for it (also followed by return/enter). Make sure not to type all capital letters. If you do, the computer may think that you have an old terminal that can't send lowercase letters and the serial driver may set itself up to send only capital letters to the terminal.
If nothing happens, make sure that both the host computer and the terminal are OK. If the host computer is shut down (no power) what you type at the terminal keyboard may appear on the screen since the transmit and receive pins at the computer may be connected together resulting in echoing of characters by an "off" computer. If you can't log in when the host computer is running, see Trouble-Shooting.
When typing at the command line, the shell (such as the Bash shell) is reading what you type and reacting to it. What you type first passes thru the terminal driver part of your operating system. This driver may translate certain characters (such as changing the "return" character generated by the "return" key into a "new-line" character for Linux files). It also recognizes certain control codes which you may type at the keyboard such as ^C to interrupt the execution of a program. It also normally echoes what you type back to the display. Stty may be used to configure how this terminal driver behaves, including disabling some (or all) of its functionality.
There may be some problems with using both emacs and vi on some terminals.
If software flow control exists, then the ^S command in emacs will freeze the display. The ^Q command will unfreeze the display. The fix is to map this to another key-press by configuring emacs that way.
Vi uses the esc-key as a command to exit insert mode. If one hits an arrow-key (cursor-key) an escape sequence (starting with the ESC character) is sent to the host. Vi must distinguish between these two meanings of ESC. A smart vi (such as vim if configured for it) is able to detect the difference by noting the time between the ESC and the next key. If it's a short time, then it's likely that a cursor key was pressed. Use "help cursor-keys" in vim to find out more.
Here's another way to fix this. On VT terminals the left-arrow-key may be either set to send ESC [ D or ESC O D. The other arrow keys are similar but use A, B, and C instead of D. If you're having problems, choose ESC [ D since the "O" in the other alternative could be interpreted by vi as a command to "Open a line". The "[" should be interpreted by vi to mean that an arrow-key has been pressed. ESC [ D will be sent provided "Cursor Key Application Mode" has not been set. ESC [ D is normally the default so everything is seemingly OK. Except that many termcaps contain a string (not the init string) which sets what you want to avoid: "Application Mode". Editors may send this string to the terminal when the editor starts up. Now you are in trouble.
This string has the termcap code "ks" (smkx in terminfo) meaning enable the function (and related) keys (including the arrow keys). An application enables these keys by sending the "ks" string to the terminal. Whoever wrote the termcap reasoned that if an application wants to enable these keys, then they should be put into "Application Mode" since this is an "application", but you don't want this.
The Linux console has no "ks" string so you can't fall into this trap at the console. For other terminals you may need to edit the termcap (or terminfo) or use another termcap entry. You need to change not only the "ks" string but also the termcap definitions of what they send: kd, kl, kr, ku. Then run tic to install it.
For vim (vi iMproved) there is a way to set it up to work OK with ESC O D (so you don't need to edit termcap): See vim help for "vt100-cursor-keys". You may run "gitkeys" and then press your cursor keys to see what they send but they may be set to send something different when you're in an editor.
If ls is corrupting your terminal emulation with the color
feature, turn it off. ls --color, and ls --colour all use
the color feature. Some installations have ls set to use color
by default. Check /etc/profile, etc. for ls aliases.
See
Example for ls Function for how to
have ls do color for the console and do monochrome for terminals.
The symptom of a hung terminal is where what you type doesn't display
on the terminal (or in some cases displays but doesn't do anything).
If what you type is invisible (or does nothing) type ^Q to restart flow
(if flow control stopped it). Hanging may also be due to:
Sent Terminal Binary or
Abnormally Exited a Program
If you didn't do any of these two, then your program could by buggy or
you interaction with it fatally illegal.
If you want to quit the program you were running and you can't do it by the usual methods (some programs have special keys you must hit to exit) then try killing it from another terminal using "top" or "kill". If the process refuses to die, you may try sending it signal 9 from top which should force it to exit. The "9" type of forced exit may leave some temporary files lying around as well as a corrupted interface. Killing the login shell should result in a startup of getty with a new login prompt.
People new to Linux may unintentionally press Ctrl-S (^S) (or the "No Scroll" key) which mysteriously freezes the screen (although that is what this key is supposed to do if you use software flow-control). To restore normal screen interaction, press Ctrl-Q (^Q). Note that everything typed during the "freeze" gets executed but you don't see any report of this until you hit ^Q. Thus when it's frozen, don't type anything drastic that might destroy files, etc. One argument for using hardware flow-control is to prevent such freezes.
This includes the case of a "frozen display" = "hung terminal" of the previous section.
When the display doesn't look right, or when what you type doesn't display correctly (if at all), or nothing happens when you type a command, you may have a corrupted terminal interface. In rare cases when the serial port hardware gets itself corrupted, the only fix may be to cycle power (turn off the PC and reboot). The corruption may be due to things such as bug in the program you're using, a hardware failure (including an obscure hardware defect that you can normally live with), or possibly an incorrect configuration. If everything was working normally but it suddenly goes bad, it may be that the interface got corrupted by something you did. Three mistakes you might have made to corrupt the interface are:
Your terminal will change its characteristics if sent certain escape sequences or control characters. It you inadvertently try to display a binary file, it might by chance contain such sequences which may put your terminal into some strange mode of operation or even make it unusable. Always view or edit a binary file with programs designed for that purpose so that this doesn't happen. Most editors and pagers will handle binary OK so as not to corrupt the interface. Some may display a message telling you that they can't edit binary. But using "cat ...." or "cp .... /dev/tty.." where .... is a binary file, will send the binary to the terminal and likely corrupt things.
Corruption it can also happen when using a communications program where a remote computer may send binary to your screen. There are numerous other ways it can happen so be prepared for it. Even a supposed ASCII file may contain unwanted control codes.
To fix this problem reset the terminal. You may try typing "setterm -reset" (although you may not be able to see what you're typing). This will send the reset string from the terminfo entry to the terminal. If the correct set-up has been saved inside the terminal, then pressing a special key(s) (perhaps in setup mode) may restore this setting. Then you might still need to use "tset" to send the init string if you use it to set up your terminal. Note that the "reset" command appears to be broken for terminals that have been set to "clocal" with stty or the like. I've substituted "setterm -reset" for it and submitted a bug report in Mar. 2000.
Large application programs (such as editors) often use the stty command (or the like) in their code to temporarily change the stty configuration when you are running the program. This may put the device driver into "raw" mode so that every character you type goes directly thru to the application program. Echoing by the driver is disabled so that everything you see on the screen comes directly from the application program. Thus many control commands (such as ^C) may not work within such applications.
When you tell such an application to quit, the application program first restores the stty settings to what they were before the application program started. If you abnormally exit the program (you may guess this has happened when what you type no longer displays on the screen) then you may still be in "raw mode" on the command line.
To get out of raw mode and restore the normal stty settings type "stty sane". However, you must type this just after a "return" and end it with a "return". But hitting the "return" key doesn't do the job since the "return" code no longer gets translated to the new-line characters that the shell is waiting for. So just type new-line (^J) instead of "return". The "sane" terminal interface may not be exactly the same as the normal one but it usually works. "stty sane" may also be useful to get out of a corrupted interface due to other causes.
A number of control characters which you may type at the keyboard are "caught" by the terminal driver and perform various tasks. To see these control commands type: stty -a and look at lines 2-4. They are tersely explained in the stty manual pages. They may be changed to different control characters or disabled using the stty command. Thus your control characters might be different than those described below. They are used for command-line editing, interrupting, scrolling, and to pass the next character thru transparently.
While the terminal driver has a few commands for command-line editing, some shells have a built-in real editor (such as "readline" in the Bash shell). Such an editor is normally on by default so you don't need to do anything to enable it. If it's available you don't need to learn many of the following commands although they often still work along with the command-line editor. The most important to learn are ^C (interrupt), ^D, and how to stop scrolling.
If what you want to see scrolls off the bottom of the screen, you may prevent this by sending a "stop" signal (^S or Xoff) to the host (provided Xon-Xoff Flow Control is enabled). Send a "start signal to resume (^Q or Xon). Some terminals have a "No Scroll" key which will alternately send Xoff and Xon or possibly send the hardware flow control signals ?? Here's what ctrl-S (^S) and ctrl-Q (^Q) do:
If you want to both stop scrolling and quit, use ^C. If you want to stop scrolling to do something else but want to keep the program that was generating the output in memory so you can resume scrolling later, use ^Z suspend.
An alternative scrolling method is to pipe the output thru a pager such as more, less, or most. However, the output might not be standard output but could be error output which the pager doesn't recognize. To fix this you may need to use redirection "2>&1" to get the pager to work OK. It is often simpler to just use ^S and ^Q unless you need to scroll backwards.
At a PC console (emulating a terminal) you may scroll backwards by using Shift-PageUp. This is frequently needed since the scrolling is often too fast to stop using ^S. Once you've scrolled backwards Shift-PageDown will scroll forward again.
^V sends the next character typed (usually a control character) directly thru the device driver with no action or interpretation. Echoed back are two ASCII characters such as ^C.
Some "text" files are 8-bit Latin1 (see Character-Sets). If you have a terminal that will not display Latin1 (or don't have the Latin1 character set selected), then a bullet symbol will display as a 7, etc. When viewing manual pages (they are Latin1) you may give the option -7 to man so as to translate the 7's, etc. to something close to a bullet (in ASCII). Are there some pagers that make these translations ??
These utility programs will provide information about the terminal interface:
The terminal settings are normally set once when the terminal is installed using the setup procedures in the terminal manual. However, some settings may be changed when the terminal is in use. You normally would not give any "stty" of "setserial" commands when the terminal is in use as they are likely to corrupt the terminal interface. However, there are changes you may make to the appearance of the terminal screen or to its behavior without destroying the integrity of the interface. Sometimes these changes are made automatically by application programs so you may not need to deal with them.
One direct method of making such changes is to use the setup key (or the like) at the terminal and then use menus (or the like) to make the changes. To do this you may need to be familiar with the terminal. The other 3 methods send an escape sequence from the computer to the terminal to make the changes. These 3 examples show different methods of doing this to set reverse video:
This is the easiest command to use. It uses long options (but doesn't use the normal -- before them). It consults the terminfo database to determine what code to send. You may change the color, brightness, linewrap, keyboard repeat, cursor appearance, etc.
The "tput" command is similar to "setterm" but instead of using ordinary words as arguments, you must use the abbreviations used by terminfo. Many of the abbreviations are quite terse and hard to remember.
In the example "echo ^[[7m" to set reverse video, the ^[ is the escape character. To type it type ^V^[ (or ^V followed by the escape key). To use this "echo" method you must find out what code to use from a terminal manual or from terminfo or termcap. It's simpler to use setterm or tput if you are typing on the command line. Since "echo ..." will execute faster (since it doesn't do any lookups) it's good for using in shell scripts which run at start-up, etc.
When you turn off the terminal the changes you made will be lost (unless you saved them in non-volatile terminal memory by going into set-up mode and saving it). If you want to use them again without having to retype them, put the commands in a shell script or make it a shell function. Then run it when you want to make the changes. One way to make the changes semi-permanent is to put the commands in a file that runs each time you login or start up the computer.
This is also called a "serial console". Many messages from the system are normally only sent to the console (the PC monitor). Some of the messages sent to the console at boot-time may also be seen on any terminal after the boot succeeds by typing the command: dmesg. If the boot fails this will not be of any use. It's possible to modify the Linux kernel so as to make a terminal serve as the console and receive all the messages from Linux intended for the console. Unfortunately, the messages from the BIOS (which display on the monitor when a PC is first started) will not display on this terminal.
Some people do this when they run a PC without a monitor or keyboard. Normally a PC will not start up without a keyboard and monitor but some BIOSs permit one to do it. You will likely need to set this up in the BIOS using the CMOS menus when you start your PC.
The instructions for creating a serial-console are included with source code documentation in the file: serial-console.txt. Normally, the device /dev/console is linked to tty0 (the PC console). For a serial-console you create a new /dev/console which is a true device (and not linked to something else). You must also put a statement regarding the serial-console into /etc/lilo.conf and then run lilo. This is because the equivalent of "setserial" needs to be run to set up your serial-console before the kernel is loaded. See the above mentioned documentation for more details.
Here is an example /etc/lilo.conf file contents (for ttyS0):
prompt
timeout=50
boot = /dev/sda
vga = normal # force sane state
install = /boot/boot.b
message = /boot/message
image = /vmlinuz
root = /dev/sda1
label = console
serial = 0,9600n8
append = "console=ttyS0"
The Linux Journal in April 1997 had an article on patching the Linux kernel. You add a couple of #defines at the start of src/linux/drivers/char/console.c:
#define CONFIG_SERIAL_ECHO
#define SERIAL_ECHO_PORT 0x2f8 /* Serial port address */
The following was not in the Linux Journal article.
In kernel 2.+ (and earlier ??) you need to also set the baud
rate (unless 9600 is OK). Find these 2 lines:
serial_echo_outb(0x00, UART_DLM); /* 9600 baud */
serial_echo_outb(0x0c, UART_DLL);
Change 0x0c in the line above (depending on the baud rate you want):
115200 baud: 0x01 19200 baud: 0x06 2400 baud: 0x30
57600 baud: 0x02 9600 baud: 0x0c 1200 baud: 0x60
38400 baud: 0x03 4800 baud: 0x18
If you currently use the console to select which operating system to boot (using LILO), but would like to do this from a terminal, then you need to add a line to the /etc/lilo.conf file. See the manual page for lilo.conf and search for "serial=".
Yes, you use a terminal and make it behave like the console per above. You will likely still need a video card since most BIOSs require one to get the PC started. Your BIOS may also require a keyboard to get started or it may have an option where you can set the BIOS not to require a keyboard.
The "screen" package runs multiple sessions something like
virtual terminals on the console: See
The Console: /dev/tty?. However, this is not like "pages" (
Pages) since the image of the pages are stored in
the host computer and not inside the terminal as they are with
"pages".
To log out type either "logout" or "exit". Under some circumstances your request will be refused, but you should be told why. One reason for refusal is if you are not in the same shell into which you logged into. Another way to log out is to press ^D. Since ^D is also used for other purposes, you may not want it to log you out. If you set IGNOREEOF in the Bash shell then ^D will no longer log you out.
If two persons logged into terminals on the same host computer want to chat with each other they may use the "write" or the "talk" program. On the Internet, chatting may be done using the "lynx" browser.
For spying on what someone else is doing at their terminal use the "ttysnoop" program. In "ttysnoop" the two terminals have the same status and anything typed on either keyboard appears on both screens (in the same location). So if you're really spying and don't want to be detected, you shouldn't type anything.
"ttysnoop" can be used for training with instructor and trainee sitting side-by-side, each at their own terminal. The instructor may watch what the trainee is typing and can correct any mistakes by typing it correctly. The trainee can watch what the instructor types and then try typing it. It's just like they used one terminal with both people having their hands on the keyboard at the same time.
There's one shortcoming to "ttysnoop" and that is that the terminals involved should all be (or emulate) the same type of terminal (such as vt100). Since the "Linux" emulation done by a console (monitor) and the "minicom" emulation are close to vt100 one may use ttysnoop using two PCs, one running "minicom" which emulates a terminal.
There's a non-free program called "DoubleVision" that is something like ttysnoop but does much more. Terminals may be of different types and it can remember and playback sessions on terminals so you can observe what happened in the past. The webpage is at http://www.tridia.com.
If you have another serial device (a printer, modem, etc.) that you want to connect to the same serial port that a terminal is on, then there is more involved than just plugging in the other device. This is mainly because when the getty program or shell is listening on the port, they (or the serial driver) are likely to give a response to any bytes sent to the port. Getty will respawn even if it's killed and will keep sending login prompts to the serial port (which may now be connected to another device). One way to work around this problem is to switch runlevels so that no getty program or shell is running on the port. But if your other use for the port only uses the port for output to an external device, then you may live dangerously by using the port for the other use with the shell or getty (intended for a terminal) simultaneously running on it.
For the runlevel fix, you may create another runlevel in which no
getty program runs on the port. Then you enter that new runlevel and
use the serial port for something else. To set this up you need to
edit /etc/inittab and check and/or set the runlevels at which
getty runs. For example the line: "S1:23:respawn:/sbin/getty
..." means that getty will run (on ttyS1) in runlevels 2 and 3. Now
you could have it only run in level 2 (by deleting "3") and then go to
runlevel 3 when you want to use the other serial device. Thus to use
the serial port for something else, the super-user would type "init 3"
to switch to runlevel 3. Type "init 2" to get back to runlevel 2.
Note that each runlevel may have a different set of initialization
scripts but you can change this if you want, so that the same scripts
are run in both runlevels. How the scripts and runlevels work are
different for each Linux distribution. In Debian, the explanation of
this is in /usr/doc/sysvinit but also look in
/usr/share/doc.
There's also the problem of the stty configuration of the port. When the port is being used for the terminal it has certain configurations but when say "init 3" is used to switch runlevels and disable getty on the port, the original (boot-time) configuration of the port is not restored. You are likely to wind up with the port configured in a "raw" mode. This means that the serial port likely needs to be fully reconfigured by stty, either by a script you write or by the next application which runs on the port. Some applications such as printing from the serial port are not capable of fully reconfiguring (the /etc/printcap can only partially reconfigure). Thus you may need to write a script to do it. The stty configuration of a terminal will be different depending on whether a shell is running on it, whether it's at the "login" prompt, etc. Thus the stty configuration after switching runlevels may vary.