Bug 78554 - non-ASCII characters corrupt cursor handling
non-ASCII characters corrupt cursor handling
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-25 13:52 EST by Robert M. Riches Jr.
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-11-25 14:49:08 EST
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 Robert M. Riches Jr. 2002-11-25 13:52:53 EST
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):
XFree86-4.1.0-25

How Reproducible:
100%

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.

Actual Results:
Catting a 0x96 character corrupts the cursor handling functions
of the xterm.

Expected Results:
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).

Additional Information:
	Doing 'stty -a' before and after the corruption shows no
difference.  The usual 'reset' sequence restores proper function.
Comment 1 Mike A. Harris 2002-11-25 14:35:06 EST
Can you test gnome-terminal and konsole as well and let me know if they
also exhibit this behavior?
Comment 2 Robert M. Riches Jr. 2002-11-25 14:49:01 EST
I tried both gnome-terminal and konsole, and neither one appears
to have this problematic behavior.
Comment 3 Mike A. Harris 2002-11-25 17:45:28 EST
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:

http://www.support.compaq.com/alpha-tools/redhat or
ftp://alpha.crl.dec.com/pub/linux/redhat/7.2-alpha


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