[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Locale settings done inside the shell don't affect it

From: mitr
Subject: Locale settings done inside the shell don't affect it
Date: Thu, 10 Oct 2002 22:32:41 +0200 (CEST)

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib 
-D_GNU_SOURCE  -O2 -march=i386 -mcpu=i686
uname output: Linux linux 2.4.18-14 #1 Wed Sep 4 12:13:11 EDT 2002 i686 athlon 
i386 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 2.05b
Patch Level: 0
Release Status: release

See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74701 for the whole
discussion, including references to POSIX and a patch. The original symptoms
were that running
LANG=foo bash
would behave in file globbing as if LC_COLLATE were set to foo.

Another bug of the same kind is that readline uses the charset from the
original environment, not the one set in the shell. This results in
login shells deleting UTF-8 characters byte-by-byte, see

The main problem is that bash runs setlocale (L*, ""), which uses the
values of the original environment which is not affected by the internal
bash environment. Also the language variable handling was not following
the POSIX-mandated priority handling (changing LANG would override
all locales, unsetting LC_ALL makes all categories use default_locale
instead of LC_*/LANG).
See patches at the two above mentioned bugs in Red Hat bugzilla.
I would appreciate being Cc: ed on any discussion.

reply via email to

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