Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#673206: rxvt-unicode-256color: do not display properly utf8 characters
2 views
Skip to first unread message
Nicolas Évrard
May 16, 2012, 6:10:02 PM5/16/12
to
Package: rxvt-unicode-256color
Version: 9.15-1
Severity: important
Dear Maintainer,
After my daily routine of upgrading my debian packages I noticed that
urxvt stopped displaying correctly the utf8 characters. I first
suspected a problem with lightdm (since it is one of the updated
packages) not correctly setting up the environment info. Then I
noticed that uxterm displays correctly the utf8 characters.
So I suspect there is something wrong in rxvt (it's probably related
to libfontconfig since it is one of the updated packages).
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages rxvt-unicode-256color depends on:
ii base-passwd 3.5.24
ii libc6 2.13-32
ii libfontconfig1 2.9.0-5
ii libgcc1 1:4.7.0-8
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libglib2.0-0 2.32.3-1
ii libperl5.14 5.14.2-10
ii libstartup-notification0 0.12-1
ii libx11-6 2:1.4.99.901-2
ii libxft2 2.2.0-3
ii libxrender1 1:0.9.7-1
ii ncurses-term 5.9-7
Versions of packages rxvt-unicode-256color recommends:
ii fonts-vlgothic [fonts-japanese-gothic] 20120325-1
ii ttf-dejavu 2.33-2
rxvt-unicode-256color suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Version: 9.15-1
Severity: important
Dear Maintainer,
After my daily routine of upgrading my debian packages I noticed that
urxvt stopped displaying correctly the utf8 characters. I first
suspected a problem with lightdm (since it is one of the updated
packages) not correctly setting up the environment info. Then I
noticed that uxterm displays correctly the utf8 characters.
So I suspect there is something wrong in rxvt (it's probably related
to libfontconfig since it is one of the updated packages).
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages rxvt-unicode-256color depends on:
ii base-passwd 3.5.24
ii libc6 2.13-32
ii libfontconfig1 2.9.0-5
ii libgcc1 1:4.7.0-8
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libglib2.0-0 2.32.3-1
ii libperl5.14 5.14.2-10
ii libstartup-notification0 0.12-1
ii libx11-6 2:1.4.99.901-2
ii libxft2 2.2.0-3
ii libxrender1 1:0.9.7-1
ii ncurses-term 5.9-7
Versions of packages rxvt-unicode-256color recommends:
ii fonts-vlgothic [fonts-japanese-gothic] 20120325-1
ii ttf-dejavu 2.33-2
rxvt-unicode-256color suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Nicolas Évrard
May 17, 2012, 5:50:04 AM5/17/12
to
Hello here is more information about this bug.
I notice that if I start urxvt from an xterm window then the UTF-8
characters display properly. I am a bit puzzled about the cause of the
bug.
--
(°> Nicolas Évrard
( ) Liège
`¯
I notice that if I start urxvt from an xterm window then the UTF-8
characters display properly. I am a bit puzzled about the cause of the
bug.
--
(°> Nicolas Évrard
( ) Liège
`¯
Nicolas Évrard
May 17, 2012, 5:50:04 AM5/17/12
to
Some more info again : I notice that this change has something to do
with the XTERM_LOCALE environment variable. I don't really know what
it represent but once set to something (it could be C or $LANG or
whatever then the display work as usual).
--
(°> Nicolas Évrard
( ) Liège
`¯
with the XTERM_LOCALE environment variable. I don't really know what
it represent but once set to something (it could be C or $LANG or
whatever then the display work as usual).
--
(°> Nicolas Évrard
( ) Liège
`¯
Ryan Kavanagh
May 17, 2012, 8:40:02 AM5/17/12
to
Hi,
On Thu, May 17, 2012 at 11:00:30AM +0200, Nicolas Évrard wrote:
> I notice that if I start urxvt from an xterm window then the UTF-8
> characters display properly. I am a bit puzzled about the cause of the
> bug.
I used to encounter this quite a bit on FreeBSD and found it to be an
instance of the following FAQ in urxvt(7). Could you please confirm that
it is not so in your case?
| Unicode does not seem to work?
|
| If you encounter strange problems like typing an accented character but
| getting two unrelated other characters or similar, or if program output
| is subtly garbled, then you should check your locale settings.
|
| Rxvt-unicode must be started with the same "LC_CTYPE" setting as the
| programs running in it. Often rxvt-unicode is started in the "C"
| locale, while the login script running within the rxvt-unicode window
| changes the locale to something else, e.g. "en_GB.UTF-8". Needless to
| say, this is not going to work, and is the most common cause for
| problems.
|
| The best thing is to fix your startup environment, as you will likely
| run into other problems. If nothing works you can try this in your
| .profile.
|
| printf '\33]701;%s\007' "$LC_CTYPE" # $LANG or $LC_ALL are worth a try, too
|
| If this doesn't work, then maybe you use a "LC_CTYPE" specification not
| supported on your systems. Some systems have a "locale" command which
| displays this (also, "perl -e0" can be used to check locale settings,
| as it will complain loudly if it cannot set the locale). If it displays
| something like:
|
| locale: Cannot set LC_CTYPE to default locale: ...
|
| Then the locale you specified is not supported on your system.
|
| If nothing works and you are sure that everything is set correctly then
| you will need to remember a little known fact: Some programs just don't
| support locales :(
Best wishes,
Ryan
--
|_)|_/ Ryan Kavanagh | GnuPG key
| \| \ http://ryanak.ca/ | 4A11C97A
On Thu, May 17, 2012 at 11:00:30AM +0200, Nicolas Évrard wrote:
> I notice that if I start urxvt from an xterm window then the UTF-8
> characters display properly. I am a bit puzzled about the cause of the
> bug.
instance of the following FAQ in urxvt(7). Could you please confirm that
it is not so in your case?
| Unicode does not seem to work?
|
| If you encounter strange problems like typing an accented character but
| getting two unrelated other characters or similar, or if program output
| is subtly garbled, then you should check your locale settings.
|
| Rxvt-unicode must be started with the same "LC_CTYPE" setting as the
| programs running in it. Often rxvt-unicode is started in the "C"
| locale, while the login script running within the rxvt-unicode window
| changes the locale to something else, e.g. "en_GB.UTF-8". Needless to
| say, this is not going to work, and is the most common cause for
| problems.
|
| The best thing is to fix your startup environment, as you will likely
| run into other problems. If nothing works you can try this in your
| .profile.
|
| printf '\33]701;%s\007' "$LC_CTYPE" # $LANG or $LC_ALL are worth a try, too
|
| If this doesn't work, then maybe you use a "LC_CTYPE" specification not
| supported on your systems. Some systems have a "locale" command which
| displays this (also, "perl -e0" can be used to check locale settings,
| as it will complain loudly if it cannot set the locale). If it displays
| something like:
|
| locale: Cannot set LC_CTYPE to default locale: ...
|
| Then the locale you specified is not supported on your system.
|
| If nothing works and you are sure that everything is set correctly then
| you will need to remember a little known fact: Some programs just don't
| support locales :(
Best wishes,
Ryan
--
|_)|_/ Ryan Kavanagh | GnuPG key
| \| \ http://ryanak.ca/ | 4A11C97A
Nicolas Évrard
May 17, 2012, 4:10:02 PM5/17/12
to
* Ryan Kavanagh [2012-05-17 14:00 +0200]:
export LANG=fr_BE.UTF-8
and now everything works fine.
>Hi,
>
>On Thu, May 17, 2012 at 11:00:30AM +0200, Nicolas Évrard wrote:
>> I notice that if I start urxvt from an xterm window then the UTF-8
>> characters display properly. I am a bit puzzled about the cause of the
>> bug.
>
>I used to encounter this quite a bit on FreeBSD and found it to be an
>instance of the following FAQ in urxvt(7). Could you please confirm that
>it is not so in your case?
>
>| Unicode does not seem to work?
>|
>| If you encounter strange problems like typing an accented character but
>| getting two unrelated other characters or similar, or if program output
>| is subtly garbled, then you should check your locale settings.
>|
>| Rxvt-unicode must be started with the same "LC_CTYPE" setting as the
>| programs running in it. Often rxvt-unicode is started in the "C"
>| locale, while the login script running within the rxvt-unicode window
>| changes the locale to something else, e.g. "en_GB.UTF-8". Needless to
>| say, this is not going to work, and is the most common cause for
>| problems.
Good catch : I changed my .xsessionrc to add
>
>On Thu, May 17, 2012 at 11:00:30AM +0200, Nicolas Évrard wrote:
>> I notice that if I start urxvt from an xterm window then the UTF-8
>> characters display properly. I am a bit puzzled about the cause of the
>> bug.
>
>I used to encounter this quite a bit on FreeBSD and found it to be an
>instance of the following FAQ in urxvt(7). Could you please confirm that
>it is not so in your case?
>
>| Unicode does not seem to work?
>|
>| If you encounter strange problems like typing an accented character but
>| getting two unrelated other characters or similar, or if program output
>| is subtly garbled, then you should check your locale settings.
>|
>| Rxvt-unicode must be started with the same "LC_CTYPE" setting as the
>| programs running in it. Often rxvt-unicode is started in the "C"
>| locale, while the login script running within the rxvt-unicode window
>| changes the locale to something else, e.g. "en_GB.UTF-8". Needless to
>| say, this is not going to work, and is the most common cause for
>| problems.
export LANG=fr_BE.UTF-8
and now everything works fine.
0 new messages