Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 78554

Summary:	non-ASCII characters corrupt cursor handling
Product:	[Retired] Red Hat Linux	Reporter:	Robert M. Riches Jr. <rm.riches>
Component:	XFree86	Assignee:	Mike A. Harris <mharris>
Status:	CLOSED WORKSFORME	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	alpha
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-11-25 19:49:08 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:

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