pOn Sun, Jun 15, 2008 at 12:46 PM, F. Caulier <[EMAIL PROTECTED]> wrote:
> --- Pieter Verberne <[EMAIL PROTECTED]> wrote:
>
>> On Sun, Jun 15, 2008 at 07:20:32AM -0700, F. Caulier
>> wrote:
>> > I get the following when I (as root and standard user)
>> > execute pkg_info, pkg_add or pkg_delete with Xorg on:
>> >
>> > # pkg_info
>> > perl: warning: Setting locale failed.
>> > perl: warning: Please check that your locale settings:
>> > LC_ALL = (unset)
>> > LC_CTYPE = "en_US.UTF-8",
>> > LANG = (unset)
>> > are supported and installed on your system.
>> > perl: warning: Falling back to standard locale ("C").
So something has set LC_CTYPE to en_US.UTF-8, a locale which is not
supported by OpenBSD, which results in the setlocale() call failing,
something perl complains about so that you don't blame perl when you
get broken results.
...
>> I found a workaround:
>>
>> # ln -s /usr/share/locale/en_GB.ISO8859-1
>> /usr/share/locale/en_US.UTF-8
That seems like a really bad idea to me. UTF-8 and ISO8859-1 are
fundamentally different: UTF-8 uses variable-length characters while
ISO8859-* uses fixed-width (8bit) characters. Giving the locale calls
the same data for those two is likely to result in incorrect behavior
for all characters >127. Wouldn't it be better to simply not lie and
just set the locale to en_US.ISO8859-1?
>> > The point is that, I didn't changed anything related
>> > locales and I couldn't find any config files where
>> > these locales are specified. So I'm wondering why this
>> > problem appears if I didn't change anything.
Well, have you examined all the programs involved in getting to that
shell inside xterm to see if any of them document that they alter the
environment? For example, if you use 'uxterm' instead of 'xterm' then
you'll see exactly the above behavior, as uxterm is just a script that
sets LC_CTYPE=en_US.UTF-8 and then invokes xterm with the -en option.
If nothing obvious sticks out, consider debugging further by checking
the environment seen by your .xsession (if you xdm) by adding a line
like this:
env > $HOME/.xsession-env.out
to it. Similarly, check the shell's environment by doing something
similar from your .profile.
> I tried to figure out why this problem occurs and
> following to that I noticed that this perllocale
> warning only comes up when dropping a pkg_* directly
> in xterm. When using screen in an xterm and dropping
> pkg_* to it everything will work fine. Same for tty
> shells without X where everything works fine too.
Windows inside screen inherit their environment from the original
screen process. So, how do you start the initial (daemon) screen
process? From outside X, before running xinitrc? From your .xinitrc
or .xsession? From an xterm?
> I don't know much about this terminal stuff, but if
> everything beside XTerm works fine, could it be that
> XTerm itself and not the locales are the problems'
> source? Maybe XTerm doesn't manage to pass on the
> locales correctly?
Something is setting LC_CTYPE to an unsupported value. That's the
program that needs to be fixed.
> Some questions:
> - Is this bug a dangerous one or can I ignore it safely?
perl complains about it because you may get bogus results from various
operations. That doesn't sound ignorable to me.
> - Is this a bug related to XTerm?
Insufficient data.
> - Should I set the LC_TYPE and LANG variables in
> /etc/login.conf? (Is this a clean solution?)
Why do you think that would solve the problem?
> - If I want to get the OpenBSD's default locale (is
> this C/POSIX or another one?) back what file should I
> link to whom? (Following Pieter's workaround)
Why would you do that instead of simply not setting LC_CTYPE?
> - What about copying a CL_TYPE file from [0] in to the
> concerned directory which is listed by perl?
The files in cvs are in a human-readable text source format that needs
to be 'compiled' into a binary format used by the locale subsystem, so
simply copying them would be a Bad Thing. Beyond that, there's the
question of whether the locale code in the C library will actually
handle the locale data for the *.UTF-8 locales. My guess is that the
answer is "no" and that it simply won't work. After all, if it did,
you would expect the OpenBSD developers to have included them in the
normal builds and distributions.
Making the locale stuff work 100% correctly is quite complicated and
is still, as I understand it, a work-in-progress. In the meantime,
using the ISO8859-1 locales instead of the UTF-8 locales is still,
IIRC, the recommended course.
Philip Guenther
