Red Hat Bugzilla – Bug 78554
non-ASCII characters corrupt cursor handling
Last modified: 2007-04-18 12:48:41 EDT
Description of Problem:
When some non-ASCII characters are displayed, they corrupt
the cursor handling, requiring an stty 'reset' to restore
proper function. For example, the "Mail Plus" trailer on
Yahoo mail contains an 0x96 (0226) character, and this
causes the problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. In an xterm, at a shell prompt (csh), type two 'x'
characters. Use backspace to delete them. Observe the
characters disappear as they are deleted.
2. Run 'cat' on a file containing a single 0x96 (0226)
character followed by a newline. Alternatively, use /bin/mail
to view a mail message with the "Mail Plus" Yahoo trailer.
3. Back at the shell prompt, type two 'x' characters. Use
backspace to delete them. Observe the characters remain visible
even after the cursor has passed over them.
Catting a 0x96 character corrupts the cursor handling functions
of the xterm.
The cursor handling functions (making the deleted characters
disappear) should not be corrupted by catting non-ASCII characters
(except for documented xterm escape sequences, of course).
Doing 'stty -a' before and after the corruption shows no
difference. The usual 'reset' sequence restores proper function.
Can you test gnome-terminal and konsole as well and let me know if they
also exhibit this behavior?
I tried both gnome-terminal and konsole, and neither one appears
to have this problematic behavior.
This must be an xterm specific bug then I presume, and not of greater
magnitude. The offically supported terminal emulators shipped in
Red Hat Linux are gnome-terminal and konsole, which you've indicated
seem to work ok. xterm itself is merely provided with the distribution
for end user convenience as a legacy application, however it is not
directly supported by Red Hat. Even though unsupported, I have tried
to reproduce the problem above on both alpha, x86, and ia64 using
the 7.1 releases of each, but was unable to do so.
It is possible perhaps that this is a configuration issue, but that
doesn't rule out a real bug either.
Perhaps a newer xterm from a newer XFree86 release, or from the
xterm homepage may resolve this issue for you. It is recommended
to test the latest upstream xterm release first, and if the problem
is present in that release, to report the issue directly to the xterm
author. Be sure to indicate the alpha platform, as it sounds like a
platform specific issue.
You may also wish to test Red Hat Linux 7.2/Alpha, which is available
from Hewlett Packard directly, or from their ftp site at: