Red Hat Bugzilla – Bug 65679
Pan posts in invalid charset when LC_ALL is unset
Last modified: 2008-05-01 11:38:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408
Description of problem:
Pan looks for the environment variable LC_ALL to determine what charset to use
for Content-Type. When it is unset, it seems to fall back on iso885915 which is
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Red Hat Linux 7.3 GNOME-based installation with en_GB (United Kingdom) i18n.
# LANG="en_GB" produces identical results
Actual Results: Pan posts invalid header:
Content-Type: text/plain; charset=iso885915
Expected Results: Pan should post valid header:
Content-Type: text/plain; charset=iso-8859-15
Easily fixed by placing
...or similar in /etc/sysconfig/i18n
Xlib seems to like either LANG=en_GB.ISO8859-15 or LANG=en_GB.iso885915.
Perhaps you can get away with former?
Not the pan side I am not really sure what can be done, but gmime could
be made to handle the issue more gracefully?
You could try bringing up the issue on one of the pan mailing lists.
gmime seems to assume the form "iso-%d-%d", which gives an Xlib warning. :-\
Btw LC_ALL is not a normal environment variable (see the glibc manual
for more details), but a macro: try "printenv LC_ALL".
FWIW essentially no current glibc locales (the only exception being one
Norwegen locale) have a hyphen in them...
Hmm, with 0.13.2 I seem to get:
| Content-Type: text/plain; charset=ISO-8859-1
when sending from "LANG=en_GB.iso885915 pan".
In fact AFAICT it seems to ignore the encoding part of the locale entirely.
At least the charset in the Content-Type field seems to be based now only
on the xx_YY part apartly. Need to look at the code though to see what's
Things should be better with utf-8 now, I imagine.