Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 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 Another: Keypad +: LinCon = '+' Xterm = 0x1b, 'O', 'k' This is after: initscr(); cbreak; noecho(); keypad(stdscr, 1); 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): ncurses-5.4-5 How reproducible: Always 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 3. 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. Additional info:
Created attachment 104010 [details] Test program that displays the fault Run the program as: testchar -c
> 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. See http://invisible-island.net/xterm/xterm.log.html#xterm_94 (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 recommended ? 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 modified ? 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 summarize... #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 bash input-bindings.
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 over tcp/ip (a way to 'transfer' a graphic).Something different from a clasic-terminal-connection (a way to 'transfer' characters or glyphs (glyphs == characters represented as glyphs). 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 /usr/X11R6/lib/X11/app-defaults/XTerm or 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~") to <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', 'man terminfo'). 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 Petr Raszyk