Locale settings done inside the shell don't affect it

[mitr]

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

Description:
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
LANG=bar
unset LC_COLLATE
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
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74925

Fix:
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.
Thanks,
        Mirek