Bug 990215 - Xterm SHIFT function keys not working
Xterm SHIFT function keys not working
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xterm (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Miroslav Lichvar
Desktop QE
Depends On:
  Show dependency treegraph
Reported: 2013-07-30 11:13 EDT by sqlflex
Modified: 2014-02-05 09:01 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Resource map interpreter now ignores lines where there is a leading colon before the Shift function key definition Consequence: Ignores line Fix: Remove leading colon Result: Works
Story Points: ---
Clone Of:
Last Closed: 2014-02-05 09:01:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description sqlflex 2013-07-30 11:13:21 EDT
Description of problem:
When I press SHIFT Function keys 1 – 8, xterm sends the sequence for F1 – F8 to my program rather than the sequences for F11 – F18 as defined in my resource map.
I have been using the traditional method for mapping function keys 11 - 18 for at least 12 years on all flavors of Linux without a problem until now.
Recently, I started evaluating 6.4 Redhat beta release and the traditional method no longer works.

Version-Release number of selected component (if applicable):

Redhat 6.4 beta release downloaded 7/30/13

How reproducible:  Below is the xterm command that no longer works for shifted function keys.  The function key sequence returned to my program is
the same as if the SHIFT key was not pressed.

xterm  -xrm \
        'xterm*VT100.Translations:    #override    \n\
             :Shift<Key>F1:    string(0x1b) string("[23~") \n\
             :Shift<Key>F2:    string(0x1b) string("[24~") \n\
             :Shift<Key>F3:    string(0x1b) string("[25~") \n\
             :Shift<Key>F4:    string(0x1b) string("[26~") \n\
             :Shift<Key>F5:    string(0x1b) string("[28~") \n\
             :Shift<Key>F6:    string(0x1b) string("[29~") \n\
             :Shift<Key>F7:    string(0x1b) string("[31~") \n\
             :Shift<Key>F8:    string(0x1b) string("[32~") \n\
             :~Shift<Key>F1:    string(0x1b) string("OP") \n\
             :~Shift<Key>F2:    string(0x1b) string("OQ) \n\
             :~Shift<Key>F3:    string(0x1b) string("OR") \n\
             :~Shift<Key>F4:    string(0x1b) string("OS") \n\
             :~Shift<Key>F5:    string(0x1b) string("[15~") \n\
             :~Shift<Key>F6:    string(0x1b) string("[17~") \n\
             :~Shift<Key>F7:    string(0x1b) string("[18~") \n\
             :~Shift<Key>F8:    string(0x1b) string("[19~") \n\
             :~Shift<Key>F9:    string(0x1b) string("[20~") \n\
             :<Key>Prior:    string(0x1b) string("[S")' \
    -e actflex menu M &

Steps to Reproduce:
1. Run xterm command above without the actflex application program
2. While in the xterm session, press function keys to determine which key sequence are sent to the terminal.

Actual results:

    Pressing SHIFT F4 outputs the key sequence 'ESC O S'

Expected results:

    The sequence that should be outputted is 'ESC [ 2 6 ~'

Additional info:
Comment 2 sqlflex 2013-08-12 17:30:14 EDT

The problem has been fixed.
Apparently, the leading colons on each Shift function key definition line
causes the line to be ignored.   THis was not the case in all prior
Comment 3 Miroslav Lichvar 2013-08-13 08:08:08 EDT
Thanks for the update.
Comment 4 RHEL Product and Program Management 2013-10-13 19:19:23 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 5 Miroslav Lichvar 2014-02-05 09:01:46 EST
I've looked into this more. It seems the translations are handled by the libXt library and the syntax is described here


The colon modifier apparently means to apply "any standard modifiers", e.g. shift and lock. I'm not sure why it worked before and doesn't now, but it seems to me colon shouldn't be used in your translation entries as shift is already specified there.

Please reopen if you think this is a real bug (possibly in libXt).

Note You need to log in before you can comment on or make changes to this bug.