Complete.Org: Mailing Lists: Archives: linux-help: August 2001:
[linux-help] Re: Setting locale in Debian
Home

[linux-help] Re: Setting locale in Debian

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: linux-help@xxxxxxxxx
Subject: [linux-help] Re: Setting locale in Debian
From: Tom Hull <thull@xxxxxxxxxxx>
Date: Mon, 13 Aug 2001 13:08:26 -0500
Reply-to: linux-help@xxxxxxxxx

I've seen this before. Not sure why Perl has appointed itself to be
so vocal about it: ANSI C programs always start out in C locale, and
if a call to setlocale(3) fails, they still run in C locale. A call
to setlocale(3) will fail if the requested locale's support files
cannot be found/accessed/read/etc.

Some background -- for more details, do man 3 setlocale. The locale
to determine how some functions will print or interpret data in a
manner that is consistent with a particular language and character
set. For instance, some locales will present time using a 24-hour
clock, others 12-hour clock with AM/PM. Some locales will use '.'
for the decimal point, others ','. The simplest way to specify
what locale to use is to set the LANG environment variable. LC_ALL
is a synonym for LANG; I guess LANGUAGE is as well. (Red Hat also
defines LINGUAS to the same value.) The value for LANG looks like:

  Language[_Territory][.Codeset][@Modifier]

where language is a standard two-character lower-case code (en =
english, fr = french, de = german, zh = chinese). Everything else
is optional. Territory lets one distinguish between things like
American English (en_US) and British English (en_UK). Codeset is
a character set: ISO8859-1, aka Latin-1, is a 8-bit character set
that is good for western european languages from Portuguese to
Icelandic. (ISO8859-2, aka Latin-2, is good for eastern european
latin alphabet languages like Polish and Czech.) Normally, Codeset
is only specified in languages like Japanese where there are more
than one possible character set encoding. English can be handled
by ASCII, which scarcely merits mention, but it looks like Debian
has decided to promote ISO8859-1 for English: since it is a
superset of ASCII, it works. (FWIW, I've never seen Modifier
used.)

You have two approaches to fixing your problem:

 1) Track down the missing en.ISO8859-1 locale files and install/
    restore them or patch them up with links.

 2) Track down where LANG et al. are defined and change them to
    "en_US" or "en" or "C", any of which should satisfy most
    Kansans.

I'm running Red Hat, and both of these are likely to be different
in Debian. But while the details may be different, they are very
likely to work much the same way.

In RH, the locale files are in /usr/share/locale and /usr/share/i18n.
(i18n is shorthand for internationalization, i.e., 'i', 18 letters,
and 'n'; cf. l10n for localization.) One way to track this down is
to run: strings /lib/libc.so* | fgrep /locale.

In RH, the setting of LANG et al. is handled by /etc/sysconfig/i18n.
This file is then sourced by:

  /etc/rc.d/rc.sysinit
  /etc/profile.d/lang.sh

The rc.sysinit file is read by init(8), which in turn reads the
other files in /etc/rc.d/rc.${run_level}/, which is how all of
your daemons pick up their environment. If you make a change
here, you pretty much have to reboot to get the change accepted
across the system.

The lang.sh file is read through /etc/profile when you create a
new login shell (i.e., when you log in).

Because LANG is in the environment, it gets inherited from process
to process: just changing the configuration file doesn't make any
process realize that something has changed. However, you can use
this for some testing. In particular:

  LANGUAGE=junk LANG=junk LC_ALL=junk perl --version

Will print out your error message. If you replace "junk" with "en"
you probably won't get the error message; if you replace "junk"
with "C" you certainly won't.

I may have missed some stuff here. (X, for instance, has its own
locale information, but I think it's still keyed to ANSI C.)

John Reinke wrote:
> 
> >On Sun, Aug 12, 2001 at 03:17:25PM -0500, John Reinke wrote:
> >>
> >>  For the last few weeks, every time I install a package, and sometimes
> >>  when I just run a program, I get the following error:
> >>
> >>  perl: warning: Setting locale failed.
> >>  perl: warning: Please check that your locale settings:
> >>           LANGUAGE = "en.ISO8859-1",
> >>           LC_ALL = "en.ISO8859-1",
> >>           LANG = "en.ISO8859-1"
> >>       are supported and installed on your system.
> >>  perl: warning: Falling back to the standard locale ("C").
> >>
> >>  I've tried a few solutions I've found online, including reinstalling
> >>  the locale package, but nothing helps. Any suggestions?
> >
> >You might try adding the following to either ~/.bashrc or
> >~/.bash_profile (I source .bashrc from .bash_profile for those things I
> >wan to be common between login and non-login shells, aliases, etc.):
> >
> >export LANG=en_US
> >
> >- Nate >>
> 
> All this did was change the value displayed for LANG. Otherwise, I
> still get the same messages as shown above.
> 
> What files are changed/referenced by locales? The only one that I
> found that I would edit is /etc/profile (similar to Nate's solution).
> I'm still not sure what got changed to start these warnings in the
> first place.
> 
> John
> -- This is the linux-help@xxxxxxxxx list.  To unsubscribe,
> visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi

-- 
/*
 *  Tom Hull * thull at kscable.com * http://www.ocston.org/~thull/
 */
-- This is the linux-help@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi


[Prev in Thread] Current Thread [Next in Thread]