--- Philip Guenther <[EMAIL PROTECTED]> wrote:
> 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
>
Thank you very much for this very helpful post.
As I have some plan9port programs running on the
concerned machine I thought that maybe these are
responsible for setting this UTF-8 locale (as Plan 9
is pure UTF-8), so I switched off every Plan 9 related
programs on startup. But, that didn't help.
After that I checked if the xterms which I start
through ~/.xinitrc are really xterms and not uxterms.
But everything's correct, they're only xterms.
So, if the problem occurs only with xterms which I
start during the X session through my window manager's
(dwm) keybinding the problem must be related to dwm.
And it really was, I looked at the config.h and found
that dwm executes uxterm instead of xterm. I changed
that, compiled and now everything works fine.
Thanks everybody for your support.
