Bug 169347 - "home" and "end" keys in xterm generate wrong escape sequences
"home" and "end" keys in xterm generate wrong escape sequences
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-27 06:25 EDT by Tomasz Ostrowski
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-12 20:55:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomasz Ostrowski 2005-09-27 06:25:12 EDT
Description of problem:
"home" and "end" keys in xterm generate wrong escape sequences - not matching
terminfo/termcap databases.

"home" generates "\E[1~" and "end" generates "\E[4~". According to terminfo
database proper sequences are:
$ infocmp -1 xterm | egrep khome\|kend
        kend=\EOF,
        khome=\EOH,

This causes that home/end keys do not work in several console programs in xterm:
for example "mutt", "less", "info", "pinfo". They work in other terminal
emulators, like gnome-terminal or kterm, which generate proper sequences.

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

How reproducible:
Always

Steps to Reproduce:
1. start "xterm"
2. type "cat" [enter]
3. press [home]
4. press [end]
  
Actual results:
^[[1~^[[4~

Expected results:
^[OH^[OF


Additional info:
The sequences generated by xterm are proper for linux console:
$infocmp -1 linux | egrep khome\|kend
        kend=\E[4~,
        khome=\E[1~,
Several programs do have workarounds for bad escape sequences, so home/end keys
do work in them - everything using readline, joe, vim etc.

Xterm by default also generate improper sequences: \E[H i \E[F, which are proper
for FreeBSD console according to /etc/inputrc comment.


Workaround:
Add to ~/.Xresources:

xterm*VT100.translations:       #override \
                        <Key>Home:      string(0x1b) string("OH")  \n\
                        <Key>End:       string(0x1b) string("OF")  \n\
        ~@Num_Lock      <Key>KP_Home:   string(0x1b) string("OH")  \n\
        ~@Num_Lock      <Key>KP_End:    string(0x1b) string("OF")

and relogin.
Comment 1 Mike A. Harris 2005-09-27 20:54:56 EDT
Will review for Fedora Core 5 development.  It would be a good idea to
get this changed in upstream xterm by filing a bug report in Xorg bugzilla
however, to minimize the differences between upstream xterm.
Comment 2 Tomasz Ostrowski 2005-09-28 08:35:12 EDT
I was a little wrong - xterm by default do generate proper sequences for
home/end when in so called "application cursor keys" mode, which is turned on by
every console application which support cursor keys.

We can check if xterm is in application mode by using Ctrl-Middle-Click on its
window. When there's only shell active this application mode is not turned on.
But if we start any ncurses application this mode will turn on automatically.

We can check this by the following minimal ncurses program:
#include <ncurses.h>
#include <unistd.h>
int main()
{
        initscr();
        keypad(stdscr, TRUE);
        sleep(10);
        endwin();
        return 0;
}

This will enter application mode for 10 seconds.

So, the proper workaround for this bug is to disable translations completely, by
adding a one line to ~/.Xresources
xterm*VT100.translations:       #override

Also there is no bug in xterm.
Comment 3 Jason Vas Dias 2005-10-12 20:55:29 EDT
This does appear to be "fixed" with xterm-205-1 in rawhide-20051013 - at least the
home / end keys seem to generate the correct sequences in vi, less, and
an ncurses app (dialog), with the 'Application Cursor Keys' enabled / disabled.
Comment 4 Fedora Update System 2005-11-07 14:34:50 EST
From User-Agent: XML-RPC

xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 5 Fedora Update System 2005-11-14 13:05:33 EST
From User-Agent: XML-RPC

xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

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