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 echos 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 ^Q command in emacs will freeze 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) should be able to detect the difference by noting the key that follows the esc-key.
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 either "reset" or "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 "reset" to send the init string if you use it to set up your terminal.
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 -- 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 although echo will execute a little faster. So you might use echo ... in shell scripts which deal with only one type of terminal.
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.
Many messages from the system are normally only sent to the console. While the messages generated at boot-time appear on the console, they may also be seen on a terminal after the boot succeeds by typing the command: dmesg. If the boot fails this will not be of any use, so you may want to have a terminal display the messages during the booting.
It's possible to patch the Linux kernel to do this and recompile it. This will send a terminal the messages which are normally sent only to the console. It doesn't fully make the terminal into a console since one can't re-map the keyboard nor change colors like most consoles can. The Linux Journal in April 1997 had an article on this. To patch the Linux kernel add a couple of #defines at the start of src/linux/drivers/char/console.c:
<item> #define CONFIG_SERIAL_ECHO <item> #define SERIAL_ECHO_PORT 0x2f8 /* Serial port address */
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=".
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.