Bug 165249 - bash globbing sometimes ignores locale setting
bash globbing sometimes ignores locale setting
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-08-05 16:47 EDT by Mark Brader
Modified: 2009-11-20 09:12 EST (History)
1 user (show)

See Also:
Fixed In Version: 3.0-32
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 539538 (view as bug list)
Last Closed: 2005-08-08 07:54:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Brader 2005-08-05 16:47:35 EDT
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
      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.

Additional info:
Comment 1 Tim Waugh 2005-08-06 04:45:42 EDT
Confirmed.  It seems to be forgetting to setlocale() for this syntax.
Comment 3 Tim Waugh 2005-08-08 07:54:16 EDT
Reported upstream and fixed in 3.0-32.

Note You need to log in before you can comment on or make changes to this bug.