Bug 79153 - vte does not handle some basic xterm movement control chars
vte does not handle some basic xterm movement control chars
Product: Red Hat Linux
Classification: Retired
Component: vte (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2002-12-06 09:36 EST by Sean E. Millichamp
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-09 17:17:42 EST
Type: ---
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 Sean E. Millichamp 2002-12-06 09:36:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
According to at least two different documents and one terminfo file I have
access to and empirical data xterm-compatible terminals should respond to the
following control codes:
Cursor up 1 time: \E[A
Cursor down 1 time: \E[B
Cursor forward 1 time: \E[C
Cursor back 1 time: \E[D

These should also work with an optional number immediately preceding the A, B,
C, or D indicating the number of times the cursor should move and if not
specified 1 should be the default.

This works exactly as expected in xterm.

There also appear to be other problems relating to screen drawing which I can't
diagnose until I have redefined the terminal I am using to work with vte's idea
of cursor moves (once I figure out what those are).

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

How reproducible:

Steps to Reproduce:
1. Use gnome-terminal to access a system that uses the above definitions for
xterm cursor movement.
2. Try using the cursor
3. See the A B C D get passed to the application as entered text, apparently
untrapped and the cursors unusable.

Actual Results:  The application in question displayed the letters corresponding
to the cursor control codes in the field that was selected.

Expected Results:  The cursor should have moved to another field.

Additional info:

This may or may not be an obscure problem.  I don't know how most of the xterm
definitions are written these days (until I encountered this problem yesterday I
haven't looked at using control characters to control a terminal in over 15
years).  I came across this because I'm using a brain-dead commercial
application that requires a custom terminal definition - they chose to use the
above control sequences in the terminfo file.  It works fine with gnome-terminal and xterm. Even though I can and probably will rework the custom
terminfo file once I figure out what it needs I'd still classify it as a bug.
Comment 1 Sean E. Millichamp 2002-12-06 12:22:31 EST
Okay, I recreated a new terminfo entry for the application following the xterm
definition shipped with RHL and I'm not convinced that the problem is exactly
what I had described but I am convinced there is a problem (as evidenced by
xterm working perfectly and g-t not at all).

I did some tcpdumps of the conversations between the functioning xterm and the
not-functioning g-t.  xterm transmits in the style \E[A while g-t transmits
\E0A.  If I checked g-t 1.x with zvt I'd bet it uses \E[A too.  Similarly for
the other cursor keys.

If the goal is to be xterm-compatible then I'd say it should be changed to match
Comment 2 Nalin Dahyabhai 2003-01-09 16:27:38 EST
I'm not completely certain I understand what's going on here.  Is the
application outputting the control sequence which the terminal doesn't
understand, or is the terminal sending an incorrect sequence to the application
when you press one of the arrow keys?
Comment 3 Sean E. Millichamp 2003-01-09 16:58:09 EST
The terminal is sending an incorrect sequence when the arrow keys are pressed.

By "incorrect", I mean something that is not consistent with xterm.  The control
sequence sent by xterm for the up arrow key is "^[[A".  For gnome-terminal it is

Note that this seems to be fixed in my limited testing of gnome-terminal that is
shipped in phoebe.  "Fixed" meaning the sequence transmitted by gnome-terminal
is once again consistent with xterm.

A very simple way I was using to see the differences is to run /bin/cat in xterm
and gnome-terminal and then press an arrow key, the resulting sequences are
Comment 4 Nalin Dahyabhai 2003-01-09 17:17:42 EST
Yes, that would make sense.  gnome-terminal in Phoebe gained an understanding of
XTerm keypad and cursor key modes (Sun/HP/Legacy/VT220 function key modes, too).
 Marking as resolved in Raw Hide.

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