"unsupported locale setting" error
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:/
Summary: locale.
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.
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/
getpreferredenc
setlocale(
File "/usr/lib/
setlocale
return _setlocale(
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.
Anyway, within locale.
- setlocale(LC_CTYPE, "") - seems to be the problem...
>>> locale.
'C'
>>> locale.
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/
setlocale
return _setlocale(
locale.Error: unsupported locale setting
>>> locale.
'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.
'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.
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).
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.