Bug 65679 - Pan posts in invalid charset when LC_ALL is unset
Pan posts in invalid charset when LC_ALL is unset
Product: Red Hat Linux
Classification: Retired
Component: pan (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Jens Petersen
Depends On:
  Show dependency treegraph
Reported: 2002-05-29 18:37 EDT by Daniel Rees
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-29 22:26:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Rees 2002-05-29 18:37:21 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):

How reproducible:

Steps to Reproduce:
1. Red Hat Linux 7.3 GNOME-based installation with en_GB (United Kingdom) i18n.

In /etc/sysconfig/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

Additional info:

Easily fixed by placing


...or similar in /etc/sysconfig/i18n
Comment 1 Jens Petersen 2002-08-08 03:05:47 EDT
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.
Comment 2 Jens Petersen 2002-08-08 03:13:44 EDT
gmime seems to assume the form "iso-%d-%d", which gives an Xlib warning. :-\
Comment 3 Jens Petersen 2002-08-09 04:04:03 EDT
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...
Comment 4 Jens Petersen 2002-11-28 21:09:53 EST
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".
Comment 5 Jens Petersen 2002-11-28 22:27:27 EST
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
going on.
Comment 6 Jens Petersen 2003-01-29 22:26:15 EST
Things should be better with utf-8 now, I imagine.

Note You need to log in before you can comment on or make changes to this bug.