Bug 165249 - bash globbing sometimes ignores locale setting
Summary: bash globbing sometimes ignores locale setting
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-08-05 20:47 UTC by Mark Brader
Modified: 2009-11-20 14:12 UTC (History)
1 user (show)

Fixed In Version: 3.0-32
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 539538 (view as bug list)
Last Closed: 2005-08-08 11:54:16 UTC
Type: ---

Attachments (Terms of Use)

Description Mark Brader 2005-08-05 20:47:35 UTC
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 08:45:42 UTC
Confirmed.  It seems to be forgetting to setlocale() for this syntax.

Comment 3 Tim Waugh 2005-08-08 11:54:16 UTC
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.