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)

How reproducible:

   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

      export LC_ALL=C

   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:

      echo *
      echo [a-z]*
      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
      unset LC_ALL
      LANG=en_US
      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

      LC_ALL="$LC_ALL"

   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.

Additional info: