"unsupported locale setting" error

Bug #35392 reported by Julius Minka
2
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Medium
John A Meinel

Bug Description

Bugs item #1443504, was opened at 2006-03-05 14:50
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&group_id=5470

Summary: locale.getpreferredencoding() dies when setlocale fails

Initial Comment:
I'm on Ubuntu 5.10, with Python 2.4.2-0ubuntu2, and
when I open a terminal window and run python, I get

>>> import locale
>>> locale.getpreferredencoding()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/locale.py", line 417, in
getpreferredencoding
    setlocale(LC_CTYPE, "")
  File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

However, if I su - root - or even su right back to my
own account (catherine) ! - then everything works.

This is of concern (to me, anyway) because this error
crashes bzr.

I chose "Esperanto" as my language when setting up
Ubuntu. (No, I wasn't trying to be funny - I really do
speak Esperanto!) That may be why I found the problem,
but I don't think this is simply a problem with flawed
Esperanto support in Ubuntu - because the routine works
after su is used, and because
locale.nl_langinfo(CODESET) works fine (please read on).

Anyway, within locale.getpreferredencoding(), line 417
- setlocale(LC_CTYPE, "") - seems to be the problem...

>>> locale.setlocale(locale.LC_CTYPE)
'C'
>>> locale.setlocale(locale.LC_CTYPE, "")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/locale.py", line 381, in
setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>> locale.setlocale(locale.LC_CTYPE, None)
'C'

This makes me wonder if setlocale(LC_TYPE, "") is
really so very necessary. It seems to be there to prep
for the nl_langinfo call, but it doesn't actually seem
strictly necessary for that call to work.

>>> locale.nl_langinfo(locale.CODESET)
'ANSI_X3.4-1968'

... I get that result whether before or after calling
setlocale, and I get it under any account (including
root, where setlocale does not raise an exception).

Thus, as far as I can tell, it isn't really necessary
to set setlocale(LC_CTYPE, "") or die trying, and
accepting the nl_langinfo result without a
successful setlocale(LC_CTYPE, "") would be preferable
to raising an unhandled exception. I suggest that
setlocale(LC_TYPE, "") be enclosed in a try block.

                try:
                    setlocale(LC_CTYPE, "")
                except:
                    None

Since I don't really understand what it's doing in the
first place, I don't know if this is really a good patch.

Thanks!

----------------------------------------------------------------------

I've got the same problem with bzr on Gentoo. If LANG or
LC_ALL consists '/', then bzr has the problem (e.g. en_US is
ok, en_US/ISO8859-1 is wrong).

Related branches

Revision history for this message
Martin Pool (mbp) wrote :

I can reproduce this too when $LANG is set to a locale not supported by the system.

As the original poster suggests, we should perhaps emit a warning but continue with some default encoding.

Changed in bzr:
assignee: nobody → mbp
status: Unconfirmed → Confirmed
Revision history for this message
John A Meinel (jameinel) wrote :

Possible fix available in associated branch.

Changed in bzr:
assignee: mbp → jameinel
status: Confirmed → Fix Committed
Revision history for this message
John A Meinel (jameinel) wrote :

This has been merged for bzr-0.11

Changed in bzr:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.