Red Hat Bugzilla – Bug 132951
Inconsistent xterm vs. console mapping
Last modified: 2007-11-30 17:10:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
There appears to be a significant difference between the 'special' key
mappings between a Linux console and an xterm window. This applies
particularly to the numeric keypad, but also to the arrow keys and the
Ins/Del/Hom/End block as well. These are the values returned by getch().
One particular example:
Left-Arrow: LinCon = 0x104 Xterm = 0x104
Sh-L-Arrow: LinCon = 0x104 Xterm = 0x1b, 0x4f, 0x32, 0x44
Keypad +: LinCon = '+' Xterm = 0x1b, 'O', 'k'
This is after:
c = getch(); <== the call that returns the codes
This has seriously broken a large suite of 'text' software that I was
trying to 'port into a generally graphical environment. Some of it
can be code around, by having a mapping routine in place to intercept
the extra erroneous codes and remap them back to what they should be,
but this is a clear change in behaviour and is not at all desirable.
The same problem is also present in FC3T1.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run test program to print out the values on both a standad Linux
text console and an xterm window
2. type identical keys and just watch the difference
Actual Results: Linux console continues to return the same results as
it has since Slackware 2!
Xterm produces completely different character sequences for most of
the function/activity/keypad keys, both in shift and unshifted mode
Expected Results: The final (ie delivered to the application code)
ket sequences, as KEY_END, KEY_LEFT and so on, should have been mapped
through to the application code.
Created attachment 104010 [details]
Test program that displays the fault
Run the program as:
> Actual Results: Linux console continues to return the same
> results as it has since Slackware 2!
not exactly (there have been several changes, and listing them
would make this discussion longer than necessary).
xterm's behavior is settable by resources, of course.]
Linux console is hardcoded (and doesn't correspond to
either vt100 or vt220, notwithstanding the documentation).
xterm doesn't emulate Linux console. It emulates a vt102
or vt220, with various adaptations for users.
(the behavior you're referring to has been in xterm for
more than five years).
Notwithstanding what original physical terminal xterm is or is not
supposed to emulate (which I agree would be a sterile argument and
one that I didn't intend to get into - please accept my apologies for
appearing to argue that way), my immediate concern is the failure of
ncurses to produce simple keymappings that it does correctly produce
when in a Linux console environment, with the environment variable
TERM set correctly in each case.
The test program clearly shows that while the unshifted arrow keys,
Insert and Delete are correctly mapped to KEY-LEFT/RIGHT/UP/DOWN, etc.
the keys HOME, END and the numeric keypad "/*-+" keys all generate
escape sequences rather than the simple "/*-+" keys.
If there is an easy way to remedy this situation, I'd be delighted to
hear it. I have whole suite of software which works in Linux console
and does no terminal dependent stuff at all, using all the ncurses-
defined KEY_XXX labels. When I move it to xterm, it breaks. Why?
ncurses is using $TERM to find a terminfo entry that describes
the keys. First, your $TERM doesn't describe the shifted keys
that xterm is sending and second, terminfo doesn't list all of
the combinations. The xterm-new entry lists the useful combinations
for function-keys. Numeric keypad isn't listed in the terminfo.
Applications can use those (for instance using define_key, or by
providing customized terminfo entries).
It's not clear why you expect key modifiers to do nothing.
Let's focus on the different components here:
1. HOME/END keys are indeed fixed by changing the default setting
of the TERM environment variable from 'xterm' to 'xterm-new'.
Thank you for that. Is this now a distribution bug/fault that
FC2 sets the default TERM for xterm to a broken/obsolete
terminfo entry 'xterm' instead of the better one you
2. we were surprised that the Linux console ignored Shift for the
arrow keys, but considered this to be 'normal'. Now that the
xterm does generate the Shift-key sequences, we can choose
whether to support them or not. Problem solved. Why do the
keypad "/*" generate Shift, Control and Alt sequences whilst
the keypad "+-" entries don't appear to generate codes when
3. Why aren't the numeric keypad entries listed in terminfo, given
that ncurses contains an explicit call keypad(scr, mode) to
make use of these definition. Are you saying that on an xterm,
the call to keypad() is a null operation ?
For #1 - see #128138 (and related bugs). I won't attempt to
#2, Keypad +/- are used for stepping through the font menu.
#3, terminfo describes the most common features of many different
terminals. While some terminfo entries list the numeric keypad
keys as function-keys, that would interfere with the normal
assignment of F1, etc., to function keys. Standard terminfo
entries can have only 64 function-keys (and for instance, xterm-new
uses some of those for the modifiers).
ncurses (from 5.0 on) allows extensions to the terminfo, but that's
not often used for various reasons (not a technical limitation).
The keypad processing state seems to be lost when executing a sub-
program in an xterm which isn't lost when in Linux console. Program
saves the content of the screen so that it can be repainted
afterwards, then does the standard sort of fork/exec/wait sequence,
restores the screen and does refresh(). The screen appears to be
fine, but the setting of keypad(stdscr, 1) has been lost and needs to
be re-invoked to get it to work again. Why is this ?
That sounds like the subprocess is resetting the keypad to
normal mode. Generally (Linux console is an exception),
termcap/terminfo entries set application mode (a different
set of escape sequences) for the cursor-keys and keypad-keys.
If it's being reset in that manner, that's probably a workaround
to "keep" the keys in normal mode, e.g., to work with hardcoded
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Not each terminal (terminal emulator) has (knows) all 'keys'.
That is why not each terminal (terminal-emulator) emits all possible
keys. This is a proprety of a terminal (terminal emulator) (to emit a key).
A termnal-emulator emulate a hard-ware-terminal
(for instance vt100 <-- this hard-ware definitly exists somewhere.
It has not all keys that you have on your keyboard today).
A special case is 'xterm' or 'linux-console' (it emulates something, that
does not exist and did not exist as 'hard-ware').
NOTE: X-Terminal exists, but the communication protocol is X-Windows-protocol
(a way to 'transfer' a graphic).Something different from a
(a way to 'transfer' characters or glyphs (glyphs == characters represented as
If the linux-console emits the same key for the key '+' and the keys
" Keypad '+' ", this is a terminal (terminal-emulation) property.
If the xterm-emulator emits different keys for the key '+' and the keys
" Keypad key '+' ", this is a terminal (terminal-emulation) property.
You are right, that 'shift-arrow-left' in 'xterm' should be
converted (via ncurses) to a 'number' (the function call getch()
should return one number, not a sequence of numbers/characters (ESC-sequence).
In FEDORA CORE the keys "shift-arrow-left" (in xterm) return a unique number==393.
In FEDORA CORE the key " Keypad '+' " (in xterm) returns a unique number==27==ESC.
NOTE: 1) ncurses 5.4 returns ESC-key if the key is unknown.
2) You can watch all keys know by ncurses in /usr/include/curses.h
(search KEY_LEFT (arrow-left) and KEY_SLEFT (shift-arrow-left).
3) ncurses supports 'common' keys used by terminals (terminal-emulators).
xterm is a special case. You can modify/add key/new-keys in
create a copy of .../XTerm in a directory and set
shell-environment-variable XAPPLRESDIR to this directory
(for instance "export XAPPLRESDIR=$HOME" ).
Then, you can change:
<Key>Delete: string(0x1b) string("[3~")
<Key>Delete: string(0x1b) string("XQI")
If you press the Del-key in 'xterm', the xterm emits to your
application \EXQI instead of \E[3~
ncurses 5.4 can not 'catch' this 'new-esc-sequence' (you must change
the "kdc1"/"kD" in terminfo/termcap (see 'man termcap',
I see only a way to write/modify your own terminal-emulator to support all
possible keys. This was by the pterm-clone done.
See at www.c-frame.com/downpage25.
Install and doubleclick the icon pterm8x16. Launch tc-frame.
The pterm-clone-source is at www.c-frame.com/changes/changes.html