mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
gferg
parent
003e7cb61a
commit
3144bcb4bd
|
|
@ -13,6 +13,11 @@
|
|||
</author>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1.6</revnumber>
|
||||
<date>19 Jan 2002</date>
|
||||
<revremark>Included many comments from Alex Boldt and Chung-Rui Kao.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v1.5</revnumber>
|
||||
<date>3 May 2000</date>
|
||||
|
|
@ -53,6 +58,7 @@
|
|||
|
||||
<sect1 id="intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
|
||||
<para>Every Linux user has been sooner or later trapped in a situation in
|
||||
which having working <keycap>Backspace</keycap> and <keycap>Delete</keycap>
|
||||
|
|
@ -88,8 +94,8 @@
|
|||
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 <ulink
|
||||
url="http://www.debian.org/doc/debian-policy/ch3.html#s3.8">Debian keyboard
|
||||
guidelines</ulink>.</para>
|
||||
url="http://www.debian.org/doc/debian-policy/">Debian keyboard
|
||||
policy</ulink>.</para>
|
||||
</note>
|
||||
|
||||
</sect1>
|
||||
|
|
@ -117,15 +123,17 @@
|
|||
<para>The keycodes are translated by the keyboard library into a
|
||||
<firstterm>keyboard symbol (keysym)</firstterm> using the keyboard
|
||||
definition loaded by the user. If you look into your keyboard database
|
||||
(e.g., under Red Hat Linux, in <filename>/usr/lib/kbd/</filename>),
|
||||
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 <keycap>Alt</keycap> keys really behave
|
||||
as distinct modifiers). The Linux console keyboard layout assigns
|
||||
keysym <keysym>Delete</keysym> to keycode 14 and keysym
|
||||
(e.g., in <filename>/lib/kbd/</filename>), 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 <keycap>Alt</keycap> keys really behave as distinct
|
||||
modifiers). The Linux console keyboard layout assigns keysym
|
||||
<keysym>Delete</keysym> to keycode 14 and keysym
|
||||
<keysym>Remove</keysym> 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.</para>
|
||||
work in that realm.<footnote><para>This claim has been
|
||||
asserted/disputed several times commenting this document. If you have
|
||||
any definitive information on this subject, please write me.</para></footnote></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -147,7 +155,15 @@
|
|||
into a <firstterm>key capability</firstterm>. This goal is reached by a
|
||||
<firstterm>terminal database</firstterm>, 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).</para>
|
||||
capabilities (which are essentially a subset of the keysyms).<footnote>
|
||||
<para>Some programs rely on the terminal driver for input line editing,
|
||||
such as deleting characters or words. With <command>stty</command>, you
|
||||
can tell the terminal driver what character it should use to delete the
|
||||
character to the left of the cursor (the <firstterm>erase</firstterm>
|
||||
character). You can check your current settings with <command>stty
|
||||
-a</command> and set them with <command>stty erase
|
||||
<replaceable>character</replaceable></command>.</para></footnote></para>
|
||||
|
||||
|
||||
<note>
|
||||
<para>Unfortunately, there are two <quote>standard</quote> terminal
|
||||
|
|
@ -239,7 +255,7 @@
|
|||
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
|
||||
<application>XEmacs</application> is not plagued by the problem: X
|
||||
translates keycode 14 to keysym <keysym>BackSpace</keysym> and keycode 111
|
||||
translates keycode 22 to keysym <keysym>BackSpace</keysym> and keycode 107
|
||||
to keysym <keysym>Delete</keysym>, 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
|
||||
|
|
@ -277,11 +293,15 @@ bash$ export TERM=gnome
|
|||
<firstterm>standard</firstterm> a VT100 emulator behaving like the console,
|
||||
and <firstterm>deviant</firstterm> one that emits <symbol>BS</symbol> for
|
||||
<keycap>Backspace</keycap> and <symbol>DEL</symbol> for
|
||||
<keycap>Delete</keycap>. Thus, for instance,
|
||||
<application>xterm</application> 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
|
||||
<application>gnome-terminal</application> is even more erratic.</para>
|
||||
<keycap>Delete</keycap>.<footnote><para>Also these definitions have been
|
||||
asserted/disputed several times commenting this document. If you have any
|
||||
definitive information on this subject, please write me.</para></footnote>
|
||||
Thus, for instance, <application>xterm</application> 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
|
||||
<application>gnome-terminal</application> is even more erratic. See <xref
|
||||
linkend="morehack"> for some information on how to turn a deviant terminal
|
||||
into a standard one.</para>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
|
@ -364,11 +384,12 @@ a deviant one.
|
|||
<para>However, <application>gnome-terminal</application> uses by
|
||||
default the same entry as <application>xterm</application>, so if one
|
||||
is deviant and the other one is not you will need to find a way to tell
|
||||
them apart. Theoretically, the option <literal>termname</literal> of
|
||||
<application>gnome-terminal</application> should allow the user to set
|
||||
the <envar>TERM</envar> variable to a more sensible name. However, as
|
||||
of <application>gnome-terminal</application> 1.2.1 the option does not
|
||||
work.</para>
|
||||
them apart. The option <literal>termname</literal> of
|
||||
<application>gnome-terminal</application> allows the user to set the
|
||||
<envar>TERM</envar> variable to a more sensible name. However, in older
|
||||
versions of <application>gnome-terminal</application> the option does
|
||||
not work. Moreover, sometimes it is not easy to modify the way
|
||||
<application>gnome-terminal</application> is started.</para>
|
||||
|
||||
<para>A good idea here is to exploit the fact that
|
||||
<application>gnome-terminal</application> sets the
|
||||
|
|
@ -632,6 +653,59 @@ generate it.
|
|||
</note>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="morehack">
|
||||
<title>More Hacking</title>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>It could happen that, for some reason, what I said talking about
|
||||
<link linkend="x">X</link> is not true, that is, X does
|
||||
<emphasis>not</emphasis> translate keycode 22 to keysym
|
||||
<keysym>BackSpace</keysym> and keycode 107 to keysym
|
||||
<keysym>Delete</keysym> (or even that, on your particular keyboard, the
|
||||
keycodes associated to <keycap>Backspace</keycap>/<keycap>Delete</keycap>
|
||||
are not 22 and 107). To be sure of that, you need to use
|
||||
<command>xev</command>, 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 <command>xmodmap</command>, a command that lets you change many
|
||||
settings related to X keyboard handling. For instance,
|
||||
<screen>
|
||||
xmodmap -e "keycode 22 = BackSpace"
|
||||
xmodmap -e "keycode 107 = Delete"
|
||||
</screen>
|
||||
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 <varname>vt100.backArrowKey</varname>,
|
||||
<varname>vt100.translations</varname> and <varname>ttyModes</varname> of
|
||||
<application>xterm</application> (and similar terminal applications) in the
|
||||
configuration file <filename>~/.Xdefaults</filename>. One
|
||||
possibility, for instance, is
|
||||
<programlisting>
|
||||
XTerm.VT100.Translations: \
|
||||
<Key>BackSpace: string(0x7F)\n\
|
||||
<Key>Delete: string("\033[3~")
|
||||
</programlisting>
|
||||
You should take a look at the <application>xterm</application> man page for
|
||||
more information.</para>
|
||||
|
||||
<para>The program that does for the console what <command>xev</command>
|
||||
does for X is <command>showkeys</command>: it will dump the console
|
||||
keycodes of the keys you press. Combining <command>showkeys</command> with
|
||||
<command>dumpkeys</command>, which will print on standard output the
|
||||
console keymap, you can easily fix mismatches between keycodes and
|
||||
keysyms. Analogously to <command>xmodmap</command>,
|
||||
<command>loadkeys</command> 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 <filename>/lib/kbd</filename>).</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="concl">
|
||||
<title>Conclusions</title>
|
||||
|
||||
|
|
@ -639,11 +713,12 @@ generate it.
|
|||
of deleting text you wrote (however, they do not help in creating other
|
||||
text <literal>:)</literal>).</para>
|
||||
|
||||
<para>There is a small bug in the whole setting: if you start
|
||||
<para>There is a small bug in the whole setting: if you're using the
|
||||
<envar>COLORTERM</envar> trick and you start
|
||||
<application>xterm</application> from
|
||||
<application>gnome-terminal</application>, it will get <envar>TERM</envar>
|
||||
set to <literal>gnome</literal>. This inconvenience is, of course,
|
||||
harmless, and it will be solved as soon as it will be possible to start
|
||||
<application>gnome-terminal</application>, the former will get
|
||||
<envar>TERM</envar> set to <literal>gnome</literal>. This inconvenience is,
|
||||
of course, mostly harmless, and does not occur if you simply started
|
||||
<application>gnome-terminal</application> with <envar>TERM</envar> suitably
|
||||
set.</para>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue