Bug 127744 - gnu screen garbles terminal display with high ascii/unicode chars
Summary: gnu screen garbles terminal display with high ascii/unicode chars
Status: VERIFIED NORESPONSE
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: ConsoleApps (show other bugs)
Version: Final
Hardware: PC SUSE Other
: P5 - None : Normal
Target Milestone: ---
Assignee: Michael Schröder
QA Contact: E-mail List
URL:
Whiteboard:
Keywords: I18N
Depends on:
Blocks:
 
Reported: 2005-10-12 00:32 UTC by chris mccraw
Modified: 2011-05-04 15:00 UTC (History)
0 users

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
a screen capture from a screen(1) session exhibiting this bug (11.72 KB, application/octet-stream)
2005-10-12 21:12 UTC, chris mccraw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description chris mccraw 2005-10-12 00:32:40 UTC
i use fully-patched-as-of-noon-CST today (11 oct 2005) opensuse 10 on an i586 
machine.  i connect remotely via a unicode/multibyte aware rxvt terminal from 
another linux machine.  that terminal works fine for any kind of display, 
including big5 chinese characters and high-ascii (ie line drawing in centericq) 
as long as i am not running under gnu screen.

when running gnu screen *on the suse machine*, the display is heartily garbled 
by (at least) programs such as mutt which use curses upon encountering a unicode 
or big5 character (ie in spam titles).  this isn't so bad sometimes (in the 
message reader, for instance) but it's awful in the index view--the entire index 
is basically unreadable for purposes of navigating between messages.  this 
definitely seems like a bug in the screen(1) setup since i can:

1) use mutt outside of screen (in the same remote-terminal) on the suse machine 
and see unicode/big5 with no problems.
2) use mutt on a separate remote machine once connected through the screen 
session on the suse machine, and it (the remote, very different build of mutt) 
also garbles the screen
3) use mutt in the terminal without remotely connecting and all is well.

i wish i could provide more useful info, or even a better description of the 
problem, but hopefully the above is enough to clue you in.  i'll be happy to 
provide more info if you need it.

also i apologize if this bug report is misfiled, i did the best i could manage.

thanks for opensuse!  this is the only issue i've had with it so far =)
Comment 1 Michael Schröder 2005-10-12 12:11:49 UTC
okay, I need: 
1) output of 'locale' before you start screen 
2) value of $TERM before you start screen 
3) output of 'locale' after you started screen 
4) value of $TERM after you start screen 
5) output of ^A:dinfo in screen 
6) output of ^Ai in screen 
 
Thanks! 
Comment 2 chris mccraw 2005-10-12 13:37:52 UTC
here ya go.  i receive virtually no mail that is not in pure us-ascii so a 
configuration change that kills off umlauts or accents would be an acceptable 
fix.  thanks a million for looking into this!


fool@lala:[3:0]:~ > locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

fool@lala:[4:0]:~ > echo $TERM
xterm

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

fool@lala:[3:0]:~ > echo $TERM
screen

dinfo reports: (80,24) UTF-8 xterm-color iso2022
i reports: (20,21)/80x24+10000+flow UTF-8 0(tcsh)
Comment 3 Michael Schröder 2005-10-12 13:53:45 UTC
Well, all of these look good. locale says utf8, screen thinks the display uses 
utf8 and the windows are in utf8 mode as well. I have no clue why it doesn't 
work, screen should be transparent in this setup. 
 
Could you please use ^aH to start logging to screenlog.X, call mutt so that 
the display is garbled, press ^aH again to close the log and attach the log to 
this bug report? 
Comment 4 chris mccraw 2005-10-12 21:10:16 UTC
sure.  i'll attach the log below.  as an FYI, the last thing i do in the mutt 
session is hit "control-l" to redraw the screen--even that makes it worse.  i'd 
also be happy to let you login to the machine and view the mailbox in question 
to see if you could reproduce (or include the mailbox as an attachment).  let me 
know..
Comment 5 chris mccraw 2005-10-12 21:12:04 UTC
Created attachment 53884 [details]
a screen capture from a screen(1) session exhibiting this bug
Comment 6 Michael Schröder 2005-10-13 10:24:06 UTC
Can't reproduce the problem here. I tried xterm and rxvt_unicode-5.7 (is this 
the rxvt you are using?). 
Maybe screen's using some xterm escape sequence that rxvt doesn't understand, 
do you still have the problem if you use xterm instead of rxvt? 
Comment 7 chris mccraw 2005-10-13 13:30:39 UTC
yup, xterm and konsole as well as rxvt.  i use:

Usage v2.6.4 : (XPM,utmp,menubar,Kanji,graphics,.Xdefaults)
Comment 8 Michael Schröder 2005-10-13 13:59:23 UTC
Ok, some more work for you: 
1) please attach two screenshots: a garbled and a correct one. 
2) please call 'script' before starting screen, start screen and mutt to 
produce garbled output, exit screen, exit script and attach the 'typescript' 
file. 
 
I'll be on vacation until wednesday next week. I'll try to hunt down that bug 
when I'm back... 
Comment 9 Michael Schröder 2005-11-08 14:25:39 UTC
Hi, any chance for you to create the typescripts?
Comment 10 Stephan Kulow 2008-05-04 19:23:43 UTC
should we close this one? Seems highly uninteresting to both of you
Comment 11 Michael Schröder 2011-05-04 15:00:28 UTC
Yes, closing with NORESPONSE...