Bug 169347
| Summary: | "home" and "end" keys in xterm generate wrong escape sequences | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomasz Ostrowski <tometzky+redhat> |
| Component: | xterm | Assignee: | Jason Vas Dias <jvdias> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dickey, me |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-10-13 00:55:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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.
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. 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. 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. |
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.