Next Previous Contents

## 4. Resetting your terminal

There is garbage on the screen, or all your keystrokes are echoed as line drawing characters. What to do?

Many programs will redraw the screen when Ctrl-L is typed. This might help when there is some modem noise or broadcast message on your screen. The command `clear` will clear the screen.

The command `reset` will reset the console driver. This helps when the screen is full of funny graphic characters, and also if it is reduced to the bottom line. If you don't have this command, or if it does something else, make your own by putting the following two lines in an executable file `reset` in your PATH:

> `

>             #!/bin/sh
>             echo -e \\033c

> `

that is, you want to send the two characters ESC c to the console.

Why is it that the display sometimes gets confused and gives you a 24-line or 1-line screen, instead of the usual 25 lines? Well, the main culprit is the use of `TERM=vt100` (or some other entry with 24 lines) instead of `TERM=linux` when logged in remotely. If this happens on `/dev/tty2` then typing

> `

>             % cat > /dev/tty2
>             ^[c
>             ^D

> `

on some other VT (where 4 symbols are typed to `cat`: ESC, c, ENTER, Ctrl-D) and refreshing the screen on `/dev/tty2` (perhaps using Ctrl-L) will fix things. Of course the permanent fix is to use the right termcap or terminfo entry. A command that only changes the number of lines is

> `

>             % echo -e "\033[1;25r"

> `

Why is it that you sometimes get a lot of line-drawing characters, e.g., after catting a binary to the screen? Well, there are various character set changing escape sequences, and by accident your binary might contain some of these. The ESC c is a general reset, a cure for all, but if you know precisely what went wrong you can repair it without resetting other console attributes. For example, after

> `

>             % cat
>             ^N
>             ^D

> `

your shell prompt will be all line-drawing characters. Now do (typing blindly)

> `

>             % cat
>             ^O
>             ^D

> `

and all is well again. (Three symbols typed to each `cat`: Ctrl-N (or Ctrl-O), ENTER, Ctrl-D.) To understand what is happening, see `The console character sets' below.

If you loaded some strange font, and want to return to the default,

> `

>             % setfont

> `

will do (provided you stored the default font in the default place). If this default font does not contain an embedded Unicode map (and gives the wrong symbols for accented characters), then say

> `

>             % loadunimap

> `

For example, if I do

> `

>             % loadkeys de-latin1

> `

then I have a German keyboard, and the key left of the Enter key gives me a-umlaut. This works, because the a-umlaut occurs on the CP437 code page and the kernel Unicode map is initialized to CP437, and my video card has a CP437 font built-in. If I now load an ISO 8859-1 font with

> `

>             % setfont iso01.f16

> `

then everything still works, because `setfont` invalidates the kernel Unicode map (if there is no Unicode map attached to the font), and without map the kernel goes directly to the font, and that is precisely correct for an ISO 8859-1 system with `iso01.f16` font. But going back to the previous font with

> `

>             % setfont

> `

gives capital Sigma's instead of a-umlaut - all accented letters are mixed up because also this font has no embedded Unicode map. After

> `

>             % loadunimap

> `

which loads the default Unicode map (which is right for the default font) all works correctly again. Usually `loadunimap` is not invoked directly, but via `setfont`. Thus, the previous two commands may be replaced by

> `

>             % setfont -u def

> `

These days most fonts have embedded Unicode maps (often this is indicated by the extension `.psfu`), and none of this nonsense is needed anymore.

On very old terminals output involving tabs may require a delay, and you have to say

> `

>             % stty tab3

> `

(see stty(1)).

You can change the video mode using `resizecons` or `SVGATextMode`. Or by rebooting and having "vga=ask" in the LILO configuration file.

This usually settles the output side.

On the input side there are many things that might be wrong. If `X` or `DOOM` or some other program using raw mode crashed, your keyboard may still be in raw (or mediumraw) mode, and it is difficult to give commands. (See "How to get out of raw mode" below.) If you loaded a bad keymap, then

> `

>             % loadkeys -d

> `

loads the default map again, but it may well be difficult to type `-'! An alternative is

> `

>             % loadkeys defkeymap

> `

Sometimes even the letters are garbled. It is useful to know that there are four main types of keyboards: QWERTY, QWERTZ, AZERTY and DVORAK. The first three are named after the first six letter keys, and roughly represent the English, German and French speaking countries. Compared to QWERTY, the QWERTZ map interchanges Y and Z. Compared to QWERTY, the AZERTY map interchanges Q and A, W and Z, and has its M right of the L, at the semicolon position. DVORAK has an entirely different letter ordering. There are two types of Turkish keyboard. The so-called `Q'-keyboard has a QWERTY layout, while the `F'-keyboard has an entirely different layout, let us say fgGIod, where G stands for Gbreve and I for dotlessi.

## 4.1 Keyboard hardware reset

Things may be wrong on a lower level than Linux knows about. There are at least two distinct lower levels (keyboard and keyboard controller) where one can give the command "keyboard disable" to the keyboard hardware. Keyboards can often be programmed to use one out of three different sets of scancodes.

However, I do not know of cases where this turned out to be a problem.

Some keyboards have a remapping capability built in. Stormy Henderson (`stormy@Ghost.Net`) writes: `If it's your keyboard accidently being reprogrammed, you can (on a Gateway AnyKey keyboard) press control-alt-suspend_macro to reset the keys to normal.'

Next Previous Contents