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. A few terminals have no escape key (ESC) so you may need to type Ctrl-[ to get ESC.
If software flow control exists, then the ^S command in emacs will freeze the display. The ^Q command will unfreeze the display. One fix is to map this to another key-press by configuring emacs that way. Some terminals have meta keys although you may need to setup the terminal to create a meta key.
Vi uses the esc-key as a command to exit insert mode. Unfortunately for most terminals the arrow-keys send an an escape sequence (starting with the ESC character) 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 Key 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.
The scrolling speed of the text terminal is limited by the speed over the serial line. This limitation is good in one respect since the scrolling speed is slow enough that you can almost read what is scrolling on the screen before it disappears off the bottom of the screen.
But there is a downside to this. For example, if you copy a large number of files (like everything on your hard drive) and use options to display the full name (path name) of each file copied, then the speed limitations of the serial line may only only display 30 files per second on the screen. But your hard drive can copy many times faster than this but the terminal will slow down the transfer to the speed at which it can be displayed by the terminal. It does this by Flow Control.
The fix is to disable "progress" information being displayed on the screen for cases where it slows down the "progress". If it just updates progress numbers a few times per second or less, it shouldn't be a problem.
One problem still outstanding is that if certain terminal keys send bytes with the high order bit set to 1, then Bash seems to ignore the meaning for them as defined in a terminfo entry. This may be because, unless one is using 7-bit ASCII, bytes with the high order bit set to 1, may represent a non-English letter. I reported this as a bug in Bash (but years later realized that it may not have been a bug). Other programs such as the vim editor and the lynx browser work OK with such keys (when they are set to use 7-bit ASCII).
To work around this problem, one may define what these keys should do
in Bash by putting such definitions into /etc/inputrc. For
example, A Wyse 60 will send D0-D3 when the arrow-keys are hit
provided the terminal is in "application key mode". After modifying
the terminfo to reflect this, they still wouldn't work on the command
line in the Bash shell. So I explicitly defined the arrow-keys in
/etc/inputrc like this:
# Arrow keys in 8 bit keypad mode: Sends d0-d3. -ap means application.
$if term=wy60-25-ap
set enable-keypad on
"\xd0": backward-char
"\xd1": forward-char
"\xd2": next-history
"\xd3": previous-history
$endif
If the terminal is already in "application key mode" there's no need to "set enable-keypad on". enable-keypad will send the terminal the escape sequence named smkx in terminfo (which for wyse60 is \E~3 and makes the arrow keys send D0-D3). Many other applications (other than Bash) send this without needing to be told to do so.
There have been problems with the readline interface to the Bash shell. Bash 2.01 (1998) had a readline interface which was quite corrupted if one used a dumb terminal. This was fixed in later versions.
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 the program you're running
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, then kill it with signal 9 from top (or use "kill" on the command line). The "9" type of forced exit may leave some temporary files lying around as well as a corrupted interface. If this doesn't work, killing the login shell should result in a startup of getty with a new login prompt. If all else fails, you may need to reboot the computer or even power it down. Just rebooting may not alter the possibly corrupted content of the serial port hardware registers.
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). In some cases just cycling power for the terminal will fix it. Sometimes logging in again will solve the problem. To do this, kill the shell process running on the terminal (or kill getty if it's running). You may do this from another terminal. Once killed, a new getty process respawns which hopefully will end the corruption. Recycling power (or resetting) for the terminal may help too.
The corruption may be due to things such as:
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 you're likely to corrupt things if you: "cat ...." or "cp .... /dev/tty.." or run a program which sends binary output to "standard output" (unless you redirect such output with >, etc.).
Corruption 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 supposedly text file could contain unwanted control codes.
To fix this problem reset the terminal. Type either just "reset" or "tset" or "setterm -reset" (followed by a <return> of course -- what you type will likely not be readable on the screen). This will send the reset string from the terminfo entry to the terminal. As an alternative to this, if the correct set-up has been saved inside the terminal then pressing a special key(s) (perhaps in setup mode) may restore the settings. Then you might still need to use "reset" to send the init string if you use it to set up your terminal.
Note that in 2000 the "reset" command appeared to be broken for terminals that needed "clocal" set since "reset" seemed to unset "clocal". In 2001 it appears to be fixed so you may not need to read the rest of this paragraph. If you have this problem, using "reset" will only make the situation worse by disabling communication between the terminal and computer. You will likely need to log in again and hope the getty sets "clocal". If you see a login prompt without asking for it, you're in luck. Otherwise see Symptoms and some fixes for how to get a login prompt. You should try out "reset" before you need it and use "setterm -reset" if "reset" logs you out or otherwise doesn't work right. I submitted a bug report in Mar. 2000 but never got a "fixed" notice.
For the case where you see strange "graphic" characters instead of the normal ones, pressing ^O may switch back to the normal letters. The "reset" command also does this but it resets everything else too.
There's the case where all letters have the wrong attribute (too dim, bright, blinking, or even invisible :-) but the whitespace created by tab characters is normal. This was caused by an escape sequence which set this attribute but the attribute doesn't apply to the whitespace created by tab characters. Fix by resetting, etc.
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 then you may still be in "raw mode" on the command line. You should suspect this has happened when what you type no longer displays on the screen.
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 (=ISO-8859-1). See Character-Sets. If you have a terminal that will not display Latin1 (or don't have the Latin1 character set installed), then certain symbols (such as a bullet) will display wrong. When viewing manual pages (they are Latin1) you may give the option -7 to man so as to translate everything to ASCII. Are there some pagers that make these translations ??
If one uses the "man" command to view a manual page but instead redirects the output to a file, that file will have overstrikes in it. Overstrikes are where some printed characters appear bold by printing them twice in the same location. Thus to print an overstrike character the file contains a backspace after the character and then the same character repeated. If this is in a file, it's fine if you are going to print it on a printer (unless the normal output from the printer is so darks that overstriking makes little improvement). But it's not so good if you want to use the file to email or edit.
One way to get rid of the overstrikes is to use the "ul" (underline) command. You type: ul -t dumb my_overstruck_file > output_file The ul command converts overstrikes to bold for whatever terminal is specified and adds escape sequences to the output_file to generate the bold. But the terminal of type "dumb" has no escape sequences so you get the desired result. There are other ways to do this but this is a possible use for a terminal of type "dumb".
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" or "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.
The "screen" package runs multiple sessions something like
virtual terminals on the console: See
The Console: /dev/tty?. You can switch back and forth between the
sessions. The non-free Facet Term software also does this. See
FacetTerm
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 that 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" (better) program. One may prevent anyone (except the superuser) from writing (sending messages) to their terminal by using the "mesg" command.
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" (or "picocom") 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.
It's possible to use the same serial port for both a text-terminal and another serial device such as a printer or modem. Making the physical connection is easy using one of these methods:
When you are not using the serial port for a terminal, then you need to make sure that no characters intended for the terminal are sent to the other device by mistake. One unsafe way to do this is to let the programs running on the terminal keep running, provided they don't send out anything for the terminal when you are using the other device. This sometimes works since a terminal running on a serial port doesn't prevent another program (process) from opening the same port. This sometimes works if the other device is a printer. But if the other device should send bytes to the serial port on the computer, then the program(s) for the terminal which are still running on the port will often send back some bytes for the terminal which will actually go to the other device as garbage.
To avoid this, it's best to kill all programs (processes) running on the terminal before using the other device. This is not quite as easy as it sounds. You normally have a shell (such as Bash) running on the port and if you kill Bash (by logging out for example) then the program "getty" will start up on the port to try to log you in again. If you kill getty, it will respawn and start up again. So at first glance it seems impossible to kill all processes on the terminal's serial port.
One way to work around this problem is to switch runlevels so that no
getty program or shell is running on the port. For the runlevel fix,
you may create another runlevel in which no getty program runs on the
port. Then you enter this 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 distribution
dependent. For the Debian distribution, 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 may not capable of fully reconfiguring. The obsolete version of /etc/printcap could only partially reconfigure (but the new one under "lprng" can). Thus you might 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.
See 2005 Text Mode Browser Roundup for a review of text browsers.
The "lynx" browser works correctly with all text terminals. There are some other text browsers: "w3m", "links2" (formerly "links", and "elinks" that only work perfectly with the Linux console, xterm, or vt100 terminals. But links2 and elinks will work with any terminal by classifying the type as dumb like the first terminals. However, such an interface is slower.
The "netrik" browser requires a color terminal. For "links2" and "elinks" you must set your terminal to 8-bits with no parity. (I filed a bug report years ago for elinks since it should work with parity and finally in 2008 I got a message that it was fixed in version 0.13 and might become fixed in 0.11 and 0.12 also). All (including netrik ??) support ssl (secure socket layer) for encoded communication.
"w3m", "links2", and "elinks" overcome some of the "lynx" deficiencies. "elinks" is just a more advanced "links". They can usually display tables better and can display frames side-by-side. Unfortunately, the width of what they try to display (for tables and frames) is often wider than the terminal width so the text may run off the right side of the screen. This requires scrolling sideways to see everything. Doing this may cause the names of the table rows to disappear from the screen. So in some cases, using "lynx" may be better.
Unfortunately "w3m", "links2", and "elinks" don't have numbered links like lynx does, nor do they have good support for cookies. Support for Javascript may be a problem. Elinks and netrik have partial support. Links2 also has support (full ?). Both netrik and links2 has a graphic mode for use in X Window.
There are still other text browser projects. Some of them seem to be dead.