On Sat, Jun 28, 2003 at 10:09:19PM -0600, Greg Kedrovsky wrote:
> stty -a muestra "erase ^H" y no ^? (que unos dicen que es una mala
> configuraci�n; pero no s� c�mo arreglarlo).
Viene probablemente del archivo de definici�n de la terminal. En un
contexto m�s amplio, es simplemente da�o cerebral hist�rico (el da�o
es tal que a�n hoy en d�a hay gente que sigue argumentando que en
realidad no lo es). Del FAQ que acompa�a a los paquetes de XFree86 en
Debian:
Unfortunately, there are many places where things can go wrong if you think
the wrong thing is happening when you press a key in X.
Here is a procedure for diagnosing the problem:
Use the xev program (in the xbase-clients package) to determine what
keycodes and keysyms are being generated by the problematic keys. Run
xev from an xterm (or other X terminal emulator) window. Move the mouse
pointer into the window that appears and press the key(s) in question.
xev catches all X events, not just key presses and releases, so you'll
see other types of events as well. The ones of interest will look like
this:
KeyPress event, serial 18, synthetic NO, window 0x5800001,
root 0x26, subw 0x0, time 3799560301, (110,117), root:(150,276),
state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
XLookupString gives 1 characters: "
KeyRelease event, serial 21, synthetic NO, window 0x5800001,
root 0x26, subw 0x0, time 3799560385, (110,117), root:(150,276),
state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
XLookupString gives 1 characters: "
The parts on the third line about keycodes and (especially) keysyms are
the data of interest. The keycodes are system-dependent (they vary
according to the model of keyboard; Amiga keyboards and PC keyboards use
different keycodes, for instance). If this data doesn't make sense
(with one significant exception), then there is a problem with the X
server's idea of your keyboard. If you're using XKB, you may be using
the wrong parameters for your keyboard (or the XKB data could be wrong,
especially if your keyboard isn't a North American PC model). If
you're using Xmodmap, your Xmodmap configuration could be wrong. If
you're not using either one, the X server will have fallen back on
trying to get a keymap from the kernel when the server started. This
process is prone to error; it is better to use XKB or Xmodmap if
possible.
The important exception -- the seemingly nonsensical keysym -- is
sometimes BackSpace. The key in the upper-right corner of the
alphabetic section of your keyboard, above the "Enter" or "Return" key,
should always generate the "BackSpace" keysym, even if the key is
physically engraved with the word "Delete" (e.g., on Macintosh
keyboards). If, when pressing that key, you expect the cursor to move
to the left (usually erasing as it goes), that's a backspace key; it
doesn't matter what the keyboard manufacturer painted on it.
If there is some other problem with the generated keysyms, consider
asking about it on the Debian Users' mailing list
([EMAIL PROTECTED]); if you're not subscribed to that
mailing list, be sure you ask for personal replies.
If what xev says makes sense to you, and yet your X clients (xemacs,
xterm, etc.) are doing the wrong thing, the problem does not lie in the
X server, it lies in the X client. It is the X server's job to deliver
the keysym to the clients -- after that, everything is in the client's
hands.
The ways to deal with bad key behavior from clients are as varied as
the clients themselves. The following discussion is relevant to X
terminal emulation programs, specifically xterm. For help with other
programs, consult the debian-user mailing list. For reasons of space,
the following discussion delves a bit more into jargon than the rest of
this FAQ; if you have trouble understanding it, it may be best to turn
to debian-user for help.
- xterm might be translating the key events into the wrong terminal
control sequences; this part is all about X resources. As of xterm
4.0.1-1, xterm handles these translations correctly internally.
- Whatever is running in the xterm (like the shell) can be getting
bogus information from the terminfo file for the terminal type that
xterm is using. If you're not using TERM=xterm, make sure you
understand why.
- If you still haven't found satisfaction, you may have run up against
the stone wall that is inherent in emulation.
For some keys, due to frustrating historical practice, there is simply
going to be incompatibility with the Linux console. Why? Because xterm
was initially written to emulate a VT100 terminal. PC keyboards have many
more keys than a VT100. The PC keyboard resembles a VT220 keyboard much
more closely. That's why Linus Torvalds based the kernel console driver on
VT220 emulation. If you want xterm to behave more like the Linux console,
use the terminal type "xterm-vt220". What keys are affected by this
historical incompatibility? A list follows.
Backspace (or whatever you have engraved on the key in the upper-right
corner of the alphabetic section of your keyboard). All DEC VT series
terminals generate ASCII 127 when this key is pressed. Everybody who
presses that key expects a destructive backspace. At some point over the
years, some misguided people assumed that, for this key, the key engraving
should correspond to a similarly named ASCII code; namely, ASCII 8 or "BS"
(backspace). This was extremely imprudent because user expectations are
what matter, not the enforcement of some kind of mapping between ASCII and
key engravings on non-glyph keys. For instance, ASCII does not address the
notion of function keys; indeed, most of the first thirty-two codes in
ASCII are only weakly applicable to terminals in the post-teletype age, let
alone microcomputers that aren't even terminals at all. Bottom line: the
"backspace" key, the one in the upper-right of the alphabetic section,
should generate ASCII 127 ("DEL") if a DEC VT-series terminal is being
emulated. End of story. No exceptions. Both the Linux console driver and
xterm explicitly emulate DEC VT-series terminals, so the consequences for
the backspace key should be clear. The real tragedy is that at some
point, the misconception discussed crept into termcap and terminfo data for
xterms, and people got used to the backspace key (engraved with "Delete" on
VT terminals, Macintoshes, and some other keyboards) generating ASCII 8 (or
control-H) instead of ASCII 127 (or control-?), in flagrant incompatibility
with every DEC VT terminal ever made, one model of which (the VT100) xterm
was expressly written to emulate from its very inception in 1984. The good
news is, Tom Dickey, the upstream xterm maintainer, is taking steps to move
everybody back to the Good Side of the Force with XFree86 4.0. Debian's
Keyboard Policy has anticipated that move. So, if people do things
correctly, there is no incompatibility between the Linux console and xterm.
Delete. This is a key on the "editing" keypad of a PC keyboard, along with
"Insert", "Home", "End", "Page Up", and "Page Down". The violence done to
the backspace key had fallout here, with this key getting perverted to
ASCII 127 instead of the control sequence ESC [ 3 ~ like every DEC VT
terminal produced, starting with the VT220. Again, if people do things
correctly, there is no incompatibility between the Linux console and xterm.
(The DEC VT100 series had no editing keypad at all; just the alphabetic
section and a numeric keypad.) Furthermore, the key engravings on this part
of the keyboard are different on a VT220 or later and a PC, but there is
sensible and de facto standard mapping from one to the other, which works
fine if people don't butcher the delete key with ASCII 127.
The numeric keypad. This is a place where incompatibility is probably
going to have to be accepted. Why? Because they're laid out differently,
for one thing. Instead of the double-height plus key that PC keyboards
have, DEC terminals have two normal-sized ones, a minus and a comma. Also,
instead of "Num Lock", slash, asterisk, and minus across the top row, DEC
terminals have "PF1", "PF2", "PF3", and "PF4". (PF means "Pad Function".)
These were the only function keys the VT100 had; the 220 and later had a
complete row of F-keys similar to the PC keyboard along the top as well.
Furthermore, whereas the "Num Lock" key on a PC toggles the keypad between
numeric mode and mode duplicating the features of the editing keypad and
cursor keys, the DEC terminals toggled between "keypad numeric mode" and
"keypad application mode". Whereas the former maps fairly cleanly to a PC
keypad with Num Lock on, the latter does stuff utterly differently. A DEC
VT keypad in application mode generates control sequences totally different
from the editing or cursor keypads. This makes sense, because the keys
aren't engraved with "Insert", "Delete", and so forth on a VT keypad like
the PC keys are. So, you get a choice on your PC: you can either act like
a real VT, and thus confuse users who expect the numeric keypad keys to do
what their engravings lead you to believe with the Num Lock off, or you can
discard these "keypad application" functions that are present in the VT
terminals, and possibly lose functionality from applications that expect a
real VT terminal. The popular consensus seems to be with losing
functionality, because there are few extant programs that actually use
the DEC VT terminals' keypad application mode.
The function keys along the top row of the keyboard. These don't even
exist on a real DEC VT100, but they do on the 220 (and later models). Here
we get more confusion. On a real DEC, F1 through F5 are used exclusively
for communicating with the terminal's firmware for configuration, and no
information that these keys have been pressed is ever sent to the remote
host. So, in a sense, these keys "don't exist" on a real VT terminal for
purposes of communicating with an application. What most terminal emulator
authors have done is to map the PF keys from the numeric keypad to F1-F4 on
the PC. This is a reasonable compromise, and certainly better than
hijacking the Num Lock key away, which you'd have to do if you tried to do
a physical mapping between the VT keyboard and the PC. What is done about
F5 does not seem to be well-standardized.
Where PC keyboards have "Print Screen", "Scroll Lock", and "Pause", VT100's
have no keys and VT220's and later have only two keys: a double-wide "Help"
key and a "Do" key.
Finally, VT220 and later keyboards have four additional function keys above
the numeric keypad where most PC keyboards have the LED's for Caps, Num,
and Scroll Lock.
Cualquier cosa que no sea intencional y que se desv�e de lo que dice el
texto citado Est� Mal(TM).
Si quiere ver que es lo que la definici�n del archivo de terminal dice
respecto a "backspace", haga esto:
$ infocmp -1 -g | grep kbs=
y si el problema es delete:
$ infocmp -1 -g | grep kdch1=
la salida de eso, para aterm, debe ser respectivamente:
kbs=\177,
kdch1=\E[3~,
--
Marcelo
--
Desuscripci�n: escriba a [EMAIL PROTECTED], tema 'unsubscribe'
Problemas a: [EMAIL PROTECTED] http://www.linux.or.cr/listas
