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