Description of problem:
bash globbing sometimes ignores locale setting
Version-Release number of selected component (if applicable):
bash-3.0-31 (also partly reproduced in bash-2.05b-20.1)
This behavior seems to depend on exactly how the locale was set in the
environment. I can reproduce it by making sure that all LC_ variables
are unset, but LANG is set to some form of English, and then doing
LC_ALL=C export LC_ALL
This traditional syntax is supposed to be the same as
thus setting LC_ALL in the current shell itself and in the environment.
And it does that, as an echo $LC_ALL will confirm, but the current
shell fails to take account of it. These commands:
rm [a-z]* # Ouch! Where'd my capital-letter files go?
will all ignore the "C" locale and fold case, presumably respecting $LANG.
Yet $LC_ALL echoes correctly as "C", and if I start a subshell by typing
"sh", then the locale _is_ respected in the subshell.
If instead of the first syntax I use the second one mentioned above
(export LC_ALL=C), then the bug is avoided. If I set LC_ALL=C without
exporting (or with a separate export command), then the bug is avoided.
This creates the following simple demo (start in an empty directory):
touch C B A c b a
echo * # produces A a B b C c - right
LC_ALL=C export LC_ALL
echo * # produces A a B b C c again - now wrong
LC_ALL="$LC_ALL" # should be no-op
echo * # produces A B C a b c - right
All of the above is reproducible with both bash versions mentioned above,
and no matter whether bash is invoked as "bash" or "sh". But with the
newer version only, I further find that if I have successfully put LC_ALL
(set to "C") in the environment and now start a new bash subshell by
typing "bash" (rather than "sh"), this also fails to respect the locale.
Again, this behavior can be ended by typing the command
which should of course be a no-op.
If this has not been widely noticed, I suspect it may be because people
who want a locale are setting it via a .bashrc file (I don't have one)
and are using one of the other syntaxes for setting the environment
variable. Or, of course, it may depend on something I haven't thought
of mentioning as relevant.
Confirmed. It seems to be forgetting to setlocale() for this syntax.
Reported upstream and fixed in 3.0-32.