Linux Backspace/Delete mini-HOWTO
Sebastiano Vigna
vigna@acm.org
Revision History
Revision v1.6 19 Jan 2002
Included many comments from Alex Boldt and Chung-Rui Kao.
Revision v1.5 3 May 2000
Updated for new distros and the tput trick.
Revision v1.4 7 December 2000
Updated for Red Hat 7.0 and Helix Gnome conflicts.
Revision v1.3 18 October 2000
Name change.
Revision v1.2 15 October 2000
Updated. Added "What If Nothing Works" section.
Revision v1.1 13 September 2000
Added tcsh fixes
Revision v1.0 5 September 2000
First release
-----------------------------------------------------------------------------
Table of Contents
1. Introduction
2. How Keys Are Turned Into Actions
3. Why It Doesn't (Always) Work
4. X
5. What You Should Do When Writing Applications
6. What You Should Do On Your System
6.1. What Needs to Be Done
6.2. How to Do It
6.3. Fixing for tcsh
7. What If Nothing Works
8. More Hacking
9. Conclusions
1. Introduction
Every Linux user has been sooner or later trapped in a situation in which
having working Backspace and Delete keys on the console and on X seemed
impossible. This paper explains why this happens and suggests solutions. The
notions given here are essentially distribution-independent: due to the
widely different content of system configuration files in each distribution,
I will try to give the reader enough knowledge to think up his/her own fixes,
if necessary.
I assume that the Backspace key should go back one character and then erase
the character under the cursor. On the other hand, the Delete key should
delete the character under the cursor, without moving it. If you think that
the function of the two keys should be exchanged, in spite of the fact that
most keyboards feature an arrow pointing to the left (??) on the Backspace
key, then this paper will not give you immediate solutions, but certainly you
may find the explanations given here useful.
Another assumption is that the fixes should alter only local (user) files. No
standard part of the distribution should be altered. Finally, this document
discusses how to set up your system so that applications get the right
events. If an application decides to interpret such events in an
idiosyncratic way, the only possible fix is to reconfigure the application.
Note Since the first release of this Mini-HOWTO things have become even more
entangled. Different distributions of the same terminal emulator (e.g.,
gnome-terminal as provided by Red Hat 7.0, Helix Code/Ximian or even Red
Hat??7.1) generate different ASCII sequences. Due to this mismatch, now
the terminal databases correspond even less to the terminal emulators
they are supposed to describe. To set a firm ground for the following
discussion, we assume basically as correct settings the ones proposed in
the Debian keyboard policy.
-----------------------------------------------------------------------------
2. How Keys Are Turned Into Actions
When a key is pressed on the keyboard, a number of hardware and software
components cooperate so as to guarantee that the intended meaning of the key
(e.g., emitting a certain character) matches the actual behaviour of the key.
I will concentrate on the software side (as our control on the hardware part
is nonexistent), and in particular, for the time being, on the events related
to console output.
1. Hitting a key causes raw keyboard scancodes to be generated; these
scancodes are then transformed in a keycode. On an i386 system, usually
the key Backspace emits 14 and the key Delete emits 111.
2. The keycodes are translated by the keyboard library into a keyboard
symbol (keysym) using the keyboard definition loaded by the user. If you
look into your keyboard database (e.g., in /lib/kbd/), you'll discover
several definitions for different computers, different layouts and
possibly different interpretations of the same keys (e.g., one could
desire that the two Alt keys really behave as distinct modifiers). The
Linux console keyboard layout assigns keysym Delete to keycode 14 and
keysym Remove to keycode 111. This may seem strange, but the Linux
console emulates a VT100 terminal, and this is the way things work in
that realm.[1]
3. Our journey has still to come to an end. Console applications read ASCII
sequences, not keysyms. So the console must read keysyms and translate
them into ASCII sequences that suitably encode the keys. Of course, this
operation must be performed in a way that is understandable by
applications. For instance, on the Linux console the Delete keysym is
mapped to the ASCII code 127 (DEL), the Remove keysym on a suitable
escape sequence, and the BackSpace keysym to ASCII code 8 (BS).
4. Finally, we must in a sense roll back to what we had before and translate
the ASCII sequences generated by each key into a key capability. This
goal is reached by a terminal database, which contains, for each kind of
terminal, a reverse mapping from sequences of characters to key
capabilities (which are essentially a subset of the keysyms).[2]
Note Unfortunately, there are two "standard" terminal databases,
termcap and terminfo. Depending on your distribution, you
could be using either one of them, or the database could
even depend on the application. Our discussion will
concentrate on the more modern terminfo database, but the
suggested fixes take both into consideration.
For instance, on the Linux console F1 generates an escape followed by
[[A, which can be translated to the capability key_f1 by looking into the
terminal-database entry of the console (try infocmp linux if you want to
have a look at the entry). A very good and thorough discussion of
terminal databases can be found in GNU's termcap manual. Usually Linux
applications use the newer terminfo database, contained in the ncurses
package.
Maybe at this point not surprisingly, the Linux console terminfo entry
maps DEL to the kbs (backspace key) capability, and escape followed by
[3~ to the kdch1 ("delete-one-char" key) capability. Even if you could
find strange that the Backspace key emits a DEL, the terminal database
puts everything back into its right place, and correctly behaving
applications will interpret DEL as the capability kbs, thus deleting the
character to the left of the cursor.
-----------------------------------------------------------------------------
3. Why It Doesn't (Always) Work
I hope the basic problem is clear at this point: there is a bottleneck
between the keyboard and console applications, that is, the fact that they
can only communicate by ASCII sequences. So special keys must be first
translated from keysyms to sequences, and then from sequences to key
capabilities. Since different consoles have different ideas about what this
translation can look like, we need a terminal database. The system would work
flawlessly, except for a small problem: it is not always set up correctly,
and not everyone uses it.
Applications must have a way to know which database entry to use: this is
accomplished by suitably setting the TERM environment variable. In some
cases, there is a mismatch between the terminal emulator and the content of
the database entry suggested by TERM.
Moreover, many applications do not use the terminal database (or at least not
all of it), and consider BS and DEL ASCII codes with an intended meaning:
thus, without looking at the database, they assign them semantics (usually,
of course, the semantics is removing the character before or under the
cursor). So now our beautiful scheme is completely broken (as every Linux
user is bitterly aware). For instance, the bash assumes that DEL should do a
backward-delete-char, that is, backspace. Hence, on a fresh install the
Backspace key works on the console as expected, but just because of two
twists in a row! Of course, the Delete key does not work. This happens
because the bash does not look into the terminal database for the kdch1
capability.
Just to illustrate how things have become entangled, consider the
fix_bs_and_del script provided with the Red Hat distribution (and maybe
others). It assigns on-the-fly the BackSpace keysym to the Backspace key, and
the Delete keysym to the Delete key. Now the shell works! Unfortunately, all
programs relying on the correct coupling of keysym generation and terminal
database mappings are now not working at all, as the Delete keysym is mapped
to DEL, and the latter to the kbs key capability by the terminfo database, so
in such programs both keys produce backspacing.
-----------------------------------------------------------------------------
4. X
The situation under X is not really different. There is just a different
layer, that is, the X window system translates the scancodes into its own
keysyms, which are much more varied and precise than the console ones, and
feeds them into applications (by the way, this is the reason why XEmacs is
not plagued by the problem: X translates keycode 22 to keysym BackSpace and
keycode 107 to keysym Delete, and then the user can easily assign to those
keysyms the desired behaviour). Of course, a terminal emulator program
(usually a VT100 emulator in the X world) must translate the X keysyms into
ASCII sequences, so we are again in our sore business.
More in detail, usually xterm behaves exactly like the console (i.e., it
emits the same ASCII sequences), but, for instance, gnome-terminal in Red Hat
<7.0 or ??7.1 emits BS for Backspace and DEL for Delete. The real fun starts
when you realise that by default they use the same terminal-database entry,
so the fact that the kbs capability is associated to an ASCII DEL makes all
correctly behaving applications produce the same behaviour for the Backspace
and Delete keys in gnome-terminal. The simple statement
+---------------------------------------------------------------------------+
|bash$ export TERM=gnome |
+---------------------------------------------------------------------------+
can solve the problem in this case for correctly behaving applications. Well,
not always, because your system could lack an entry in the terminal database
named gnome, in particular if it is not very up-to-date.
In any case, this is not always a solution: if, for instance, you have a Red
Hat 7.0 distribution, your gnome-terminal behaves like a console. But beware:
if you upgraded your desktop using the Helix distribution, then your
gnome-terminal behaves like a pre-7.0 Red Hat.
Just to make easier the following discussion, let us define standard a VT100
emulator behaving like the console, and deviant one that emits BS for
Backspace and DEL for Delete.[3] Thus, for instance, xterm has always been
standard in the Debian distribution, while it switched a couple of times from
standard to deviant and viceversa in Red Hat; the behaviour of gnome-terminal
is even more erratic. See Section 8 for some information on how to turn a
deviant terminal into a standard one.
-----------------------------------------------------------------------------
5. What You Should Do When Writing Applications
When you write a console application, be kind to the user and try to
understand what comes from the standard input using the following fallback
chain:
1. open the right terminfo entry, and try to process the sequence so as to
discover whether it has a particular meaning on the current terminal; if
so, use the terminfo semantics;
2. use the ASCII intended meaning on line feeds, newlines, tab characters
and, of course, BS and DEL. Crossing your finger could also be useful.
-----------------------------------------------------------------------------
6. What You Should Do On Your System
Note again that the main issue that confuses people trying to fix their
system is that usually they are fixing thing in the wrong place. Since the
parts that work often just work by chance, trying to fix the system assuming
something is broken will often lead to change correct settings into incorrect
settings.
-----------------------------------------------------------------------------
6.1. What Needs to Be Done
6.1.1. Detecting Deviance
The first step towards a clean solution is to know exactly which terminals
are deviant and which not. Usually they all behave like the console, and in
this case the modifications to get everything working are minimal. If,
however, you have some deviant terminal (e.g., a deviant version of
gnome-terminal), you will have to treat it in a special way.
The following C one-liner
void main(void) {int c; while(c = getchar()) printf("%d 0x%02X\n", c, c);}
may help you. Put the line into a file named ascii.c, compile it with gcc
ascii.c -o ascii, type ./ascii and press a key followed by RETURN. The
program will display the decimal and hexadecimal codes of the ASCII sequence
produced (you may want to do a stty erase ^- first to get really all the
codes). Now you can easily see what Backspace key does: if it emits a DEL
(127), you have a standard emulator, if it emits a BS (8) you have a deviant
one.
-----------------------------------------------------------------------------
6.1.2. Distinguishing Between Emulators
If you have some deviant terminal emulator, you must distinguish it from the
standard ones. Theoretically, this should not be a problem because there are
different entries in the terminal database for terminals with different
sequences (the entry used depends on the value of the TERM variable).
Here we take the approach that the gnome entry should be used for all deviant
VT100 emulators, and the xterm entry for the standard ones. This is in line
with several distributions (except a few cases like RedHat ??5.0, where the
xterm entry is deviant).
However, gnome-terminal uses by default the same entry as xterm, so if one is
deviant and the other one is not you will need to find a way to tell them
apart. The option termname of gnome-terminal allows the user to set the TERM
variable to a more sensible name. However, in older versions of
gnome-terminal the option does not work. Moreover, sometimes it is not easy
to modify the way gnome-terminal is started.
A good idea here is to exploit the fact that gnome-terminal sets the
COLORTERM variable to gnome-terminal. Thus, by adding a simple test to the
shell configuration files we can fix the TERM variable.
-----------------------------------------------------------------------------
6.1.3. Fixing the Terminal Database
Our problem now is that the terminal database could lack a gnome entry for
deviant terminals (this happens on a number of termcap and terminfo
versions). Recent terminfo databases have an entry gnome, but, in any case,
since gnome-terminal behaves essentially like xterm modulo our famous two
keys, it is possible to automagically generate a brand new correct entry.
-----------------------------------------------------------------------------
6.1.4. Fixing the Shell Behaviour
The readline library used by the bash and by many other programs to read the
input line can be customized so to recognize specific sequences of
characters. The customization can also depend on the TERM variable, so once
we can distinguish terminals we can do fine tuning of the keyboard.
Moreover, if you want less and other application that do raw line input to
work correctly, you must convince the shell that under a deviant terminal
emulator the erase character is BS, and not DEL (in the other case the
Backspace key is already emitting DEL, so we do not have to do anything).
This can be done using the command stty.
-----------------------------------------------------------------------------
6.2. How to Do It
Caution These fixes have some drawbacks. First, they work only for the
specified terminals. Second, in theory (but this is unlikely to
happen) they could confuse the readline library on other terminals.
Both limitations are however mostly harmless.
First of all, check with infocmp gnome whether you already have a gnome entry
in your terminfo database (we will fix termcap later). If the entry does not
exist, the following command
bash$ tic <(infocmp xterm |\
sed 's/xterm|/gnome|/' |\
sed 's/kbs=\\177,/kbs=^H,/' |\
sed 's/kdch1=\\E\[3~,/kdch1=\\177,/')
will create a correct one in ~/.terminfo. If the same command is launched by
the root, it will generate the entry in the global database (you can override
this behaviour by setting TERMINFO to ~/.terminfo). Note that if your xterm
entry is already deviant (e.g., you have a Red Hat ??5.0) the script will
copy it unchanged, which is exactly what we want.
Now, add the following snippet to ~/.inputrc[4]:
"\e[3~": delete-char
This line teaches the readline library how to manage your standard Delete key
for standard emulators, and with a bit of luck it should not interfere with
other terminals. However, now we must also explain to the library the meaning
of the DEL character on deviant terminals, for instance by adding
$if term=gnome
DEL: delete-char
Meta-DEL: kill-word
"\M-\C-?": kill-word
$endif
to ~/.inputrc. If xterm is deviant, too, you must add other three lines for
it. On the other hand, if no terminal emulator is deviant this part is not
needed. All these changes can be made global by altering the /etc/inputrc
file.
Note that the conditional assignments make deviant terminal emulators work
given that the TERM variable is set correctly. To guarantee this, there are a
number of techniques. First of all, since the default value of the TERM
variable for gnome-terminal is xterm, if all terminals are not deviant then
we do nothing. If, however, a terminal that by default uses the xterm entry
is deviant you must find a way to set the TERM variable correctly; assume for
instance this is true of gnome-terminal.
The simplest way to obtain this effect is to start gnome-terminal with the
argument --termname=gnome, for instance by suitably setting the command line
in the launcher on the GNOME panel. If however you have an old version, and
this method does not work, you can add the lines
if [ "$COLORTERM" = "gnome-terminal" ]
then
export TERM=gnome
fi
to your ~/.bashrc configuration file[5]. The assignment is executed only
under gnome-terminal, and sets correctly the TERM variable.
Note Setting the terminal to gnome could prevent ls from using colours, as
many versions of ls do not know that gnome-terminal is colour capable.
To avoid this problem, create a configuration file ~/.dircolors with
dircolors --print-database >~/.dircolors, and add a line TERM=gnome to
the configuration file.
We will now generate on-the-fly a suitable termcap entry for deviant terminal
emulators; this can be done as follows, always in ~/.bashrc:
if [ "$TERM" = "gnome" ]
then
export TERMCAP=$(infocmp -C gnome | grep -v '^#' | \
tr '\n\t' ' ' | sed 's/\\ //g' | sed s/::/:/g)
fi
Finally, we must explain to the terminal device which character is generated
by the erase key. Since usually the erase key is expected to backspace, there
is a nice trick taken from the Red Hat /etc/bashrc that works: add this to ~
/.bashrc:
KBS=$(tput kbs)
if [ ${#KBS} -eq 1 ]; then stty erase $KBS; fi
It's a simple idea: we read from the terminal database the capability kbs,
and set the erase character to its value if it is a single character (which
happens in both standard and deviant terminals).
Note Certain distributions could have fixes already in place in the
system-wide /etc/inputrc configuration file. In this case you can
eliminate redundant lines from your ~/.inputrc.
-----------------------------------------------------------------------------
6.3. Fixing for tcsh
In the case of the tcsh, the fixes go all in ~/.tcshrc, and follow the same
rationale as the ones for the bash:
bindkey "^[[3~" delete-char
if ($?COLORTERM) then
if ($COLORTERM == "gnome-terminal") then
setenv TERM gnome
endif
endif
if ($?TERM) then
if ($TERM == "gnome") then
setenv TERMCAP \
"`infocmp -C gnome | grep -v '^#' | tr '\n\t' ' ' | sed 's/\\ //g' | sed s/::/:/g`"
bindkey "^?" delete-char
bindkey "^[^?" delete-word
bindkey "\377" delete-word
endif
endif
set KBS=`tput kbs`
if (${%KBS} == 1) then
stty erase $KBS
endif
The second part must be replicated for every deviant terminal. Of course, if
a termcap entry already exists it is not necessary to generate it.
-----------------------------------------------------------------------------
7. What If Nothing Works
The first thing to do is understanding which ASCII codes are produced by a
certain key using the C one-liner.
Once you know which sequences are produced, you must check the current
terminfo entry with infocmp (don't be scared by the amount of information
printed!) and be sure that the kbs and kdch1 capabilities correspond to the
right sequences (that is, the one produced by the respective keys). Moreover,
you must check with stty -a that the erase character is the one emitted by
the Backspace key (note that ^H represent BS whereas ^? represents DEL).
If there is a mismatch, there can be several different reason: wrong content
of the TERM variable, wrong entry of the terminal database, wrong terminal
emulation under X. I hope at this point you have enough information to dig
the solution autonomously.
Note If different applications behave in different ways, it is likely that
some of them are using the terminal database correctly, and some are
not. Remember that the fact that the keys produce the right behaviour in
a certain application does not mean that the application is using
correctly the terminal database??they could work just by chance. If you
want to have an independent check, you can try whether the ne editor
works. ne uses all terminal capabilities, including kbs and kdch1, and
uses intended meaning only as a last resource.
-----------------------------------------------------------------------------
8. More Hacking
So, you're not happy with the information you got. In this case, there is
even more hacking you can do on the Backspace/Delete issue, using suitable
commands that get or set the way X and the console handle keys.
It could happen that, for some reason, what I said talking about X is not
true, that is, X does not translate keycode 22 to keysym BackSpace and
keycode 107 to keysym Delete (or even that, on your particular keyboard, the
keycodes associated to Backspace/Delete are not 22 and 107). To be sure of
that, you need to use xev, a simple X application that will display the
keycode and keysym associated to the key you press. If anything goes wrong,
there are several ways you can fix the problem: the easy, temporary way is to
use xmodmap, a command that lets you change many settings related to X
keyboard handling. For instance,
+---------------------------------------------------------------------------+
|xmodmap -e "keycode 22 = BackSpace" |
|xmodmap -e "keycode 107 = Delete" |
+---------------------------------------------------------------------------+
will set correctly the keysyms (assuming that 22 and 107 are the correct
keycodes for you). In case you want to do some changes permanently, you can
play with the resources vt100.backArrowKey, vt100.translations and ttyModes
of xterm (and similar terminal applications) in the configuration file ~
/.Xdefaults. One possibility, for instance, is
XTerm.VT100.Translations: \
<Key>BackSpace: string(0x7F)\n\
<Key>Delete: string("\033[3~")
You should take a look at the xterm man page for more information.
The program that does for the console what xev does for X is showkeys: it
will dump the console keycodes of the keys you press. Combining showkeys with
dumpkeys, which will print on standard output the console keymap, you can
easily fix mismatches between keycodes and keysyms. Analogously to xmodmap,
loadkeys can then fix single associations, or load entirely new console
keymaps. With it, you can even change the string associated to a given
keysym. If you want to record these changes, you will have to define a new
keymap for the console (you should have a look at the system keymaps, usually
located in /lib/kbd).
-----------------------------------------------------------------------------
9. Conclusions
The fixes suggested here should solve to a large extent the problem of
deleting text you wrote (however, they do not help in creating other text
:)).
There is a small bug in the whole setting: if you're using the COLORTERM
trick and you start xterm from gnome-terminal, the former will get TERM set
to gnome. This inconvenience is, of course, mostly harmless, and does not
occur if you simply started gnome-terminal with TERM suitably set.
Another nontrivial problem that essentially has no solution is the one
concerning remote connections: if you connect to a host whose terminal
database is incoherent with yours, you will have to set up things manually.
Finally, it should be noted that the fixes will not work for broken
applications (for instance, applications ignoring the kbs key capability).
There is little to do in this case, as fixing for one broken application will
likely break all well-behaving ones.
Notes
[1] This claim has been asserted/disputed several times commenting this
document. If you have any definitive information on this subject, please
write me.
[2] Some programs rely on the terminal driver for input line editing, such
as deleting characters or words. With stty, you can tell the terminal
driver what character it should use to delete the character to the left
of the cursor (the erase character). You can check your current settings
with stty -a and set them with stty erase character.
[3] Also these definitions have been asserted/disputed several times
commenting this document. If you have any definitive information on this
subject, please write me.
[4] On older version of the bash, you must remember to set INPUTRC suitably,
for instance adding
export INPUTRC=~/.inputrc
to your ~/.profile (or whichever file is read just by login shells).
[5] More precisely, to the shell configuration file that is read in every
shell, not only in login shells. The right file depend on startup
sequence of your bash.
