Bug 1215460 - rxvt-unicode (urxvt) does not display unicode correctly (on recent Tumbleweed)
Summary: rxvt-unicode (urxvt) does not display unicode correctly (on recent Tumbleweed)
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: Marcus Rückert
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-18 20:05 UTC by Martin Jambor
Modified: 2023-10-19 12:02 UTC (History)
2 users (show)

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


Attachments
Screen shot of yast in screen in urxvt (9.74 KB, image/png)
2023-09-18 20:05 UTC, Martin Jambor
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Jambor 2023-09-18 20:05:18 UTC
Created attachment 869579 [details]
Screen shot of yast in screen in urxvt

After upgrading TW to version 20230828 (from some July version), urxvt  (from rxvt-unicode) does not display things correctly in GNU screen.

To reproduce:

1. open urxvt terminal and in it...
2. run screen and in it...
3. run /for example /sbin/yast

the result is garbled display (see attachments).

But that is not the only case, even GCC error and warning messages are messed up and sprinkled with "â" characters all over the place.

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


screen sets TERM to "screen-256color"
urxvt itself sets TERM to rxvt-unicode

xterm seems to work OK (with the limited capabilities it has).
Comment 1 Martin Jambor 2023-09-20 12:55:34 UTC
OK, even outside screen, rxvt-unicode cannot display non-ASCII unicode correctly, listings of files by ls containing Czech characters is incorrect (and breaks readline) too.
Comment 2 Martin Jambor 2023-09-26 15:56:11 UTC
The problem persists even after upgrading to Tumbleweed 20230922.
Comment 3 Marcus Rückert 2023-10-11 11:11:29 UTC
in https://download.opensuse.org/history/ you can find older packages. can you check if it works with the ncurses packages you had before the upgrade?
Comment 4 Marcus Rückert 2023-10-11 11:11:40 UTC
including terminfo packages.
Comment 5 Marcus Rückert 2023-10-11 11:18:12 UTC
i just noticed it isnt long enough back so you would need to osc build an older version.
Comment 6 Dr. Werner Fink 2023-10-11 12:19:52 UTC
Try this

  LANG=de_DE.UTF-8 urxvt

does Umlaute work (not the difference between UTF-8 and utf8) ... here it does and without screen also YaST does
Comment 7 Martin Jambor 2023-10-11 13:36:48 UTC
(In reply to Dr. Werner Fink from comment #6)
> Try this
> 
>   LANG=de_DE.UTF-8 urxvt
> 
> does Umlaute work (not the difference between UTF-8 and utf8) ... here it
> does and without screen also YaST does

This works!  Interestingly, using LANG=en_US.UTF-8 does not.  But LANG=C.UTF-8 also works, which might be all I need.
Comment 8 Michael Pujos 2023-10-11 18:13:32 UTC
Related:

https://bugzilla.opensuse.org/show_bug.cgi?id=1214136


Someone please patch the rxvt package with the one-liner that fixes this issue, so we do not have to wait forever for a new upstream rxvt version...
Comment 9 Martin Jambor 2023-10-13 16:10:25 UTC
After switching to LANG=C.UTF-8 everywhere all of my issues with urxvt went away, so I'm setting this to RESOLVED WORKAROUND  ...well, we don't have that state, so let's consider it FIXED (on my end) then.  Thanks!
Comment 10 Marcus Rückert 2023-10-13 18:45:02 UTC
could you check with the package in the devel project if the issue has improved with your old settings?

in general I would always suggest to use the UTF-8 versions of the locales.
Comment 11 Dr. Werner Fink 2023-10-19 12:02:55 UTC
(In reply to Martin Jambor from comment #9)
> After switching to LANG=C.UTF-8 everywhere all of my issues with urxvt went
> away, so I'm setting this to RESOLVED WORKAROUND  ...well, we don't have
> that state, so let's consider it FIXED (on my end) then.  Thanks!

Run

 info libc 'Locale Names'

to see that this is not a workaround but the real solution that is do not mix
the basename self-named directories below /usr/lib/locale/ and the name of the locale them selfs.