Bug 165249 - bash globbing sometimes ignores locale setting
bash globbing sometimes ignores locale setting
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks:
  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)
Environment:
Last Closed: 2005-08-08 07:54:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
      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:
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.