Bug 78554 - non-ASCII characters corrupt cursor handling
Summary: non-ASCII characters corrupt cursor handling
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.1
Hardware: alpha
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-25 18:52 UTC by Robert M. Riches Jr.
Modified: 2007-04-18 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-11-25 19:49:08 UTC
Embargoed:


Attachments (Terms of Use)

Description Robert M. Riches Jr. 2002-11-25 18:52:53 UTC
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 19:35:06 UTC
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 19:49:01 UTC
I tried both gnome-terminal and konsole, and neither one appears
to have this problematic behavior.


Comment 3 Mike A. Harris 2002-11-25 22:45:28 UTC
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.