Bug 118443 - In a script, bash erroneously includes files that start with an uppercase letter in the glob [a-z]*
In a script, bash erroneously includes files that start with an uppercase let...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: bash (Show other bugs)
2.1
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Pete Graner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-16 14:35 EST by John Caruso
Modified: 2007-11-30 17:06 EST (History)
0 users

See Also:
Fixed In Version: 5.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-18 03:39:01 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 John Caruso 2004-03-16 14:35:14 EST
Description of problem:
In a script, bash erroneously includes files that start with an 
uppercase letter in the glob [a-z]*.

Version-Release number of selected component (if applicable):
bash 2.05 release 8

How reproducible:
Run this script:

----- 8< --------------------------------------
#!/bin/bash

mkdir -p /var/tmp/globtest > /dev/null 2>&1
cd /var/tmp/globtest || exit 1
rm -f *
touch capybara
touch CAPYBARA
touch hippo
touch vole
touch VOLE

for LOWERCASE in [a-z]*; do
        echo $LOWERCASE should start with a lowercase letter.
done
----- 8< --------------------------------------


Steps to Reproduce:
1. Run that script.
  
Actual results:
Files starting with both lowercase and uppercase letters are listed.

Expected results:
Only files starting with lowercase letters are listed.

Additional info:
Works just fine (i.e., lists only the correct files) if you cut and 
paste the commands into an interactive bash shell.  Also works with 
zsh (unchanged) and csh/tcsh (with appropriate modifications).
Comment 1 John Caruso 2004-03-16 14:49:37 EST
Ok, I know what's coming (after doing another bug search that was 
more fruitful).  The question then becomes: why does RHAS 2.1 use a 
default setting for LANG (en_US, in this case) that produces such 
badly broken bash behavior?
Comment 2 John Caruso 2004-03-16 14:53:09 EST
And, which is the correct (or preferred) fix: setting LANG=C, setting 
LC_COLLATE=C, or both?  And what are the downsides?  If RHAS 2.1 sets 
those defaults (which we haven't touched since the installation), 
surely there must be some good reason for it, considering the extreme 
damage that can result from having file globs behave in this manner.
Comment 3 Tim Waugh 2004-03-16 16:13:49 EST
Reassigning to distribution, since this is not to do with bash.
Comment 4 John Caruso 2004-03-16 18:07:38 EST
And, why does the behavior differ between an interactive bash shell 
and a bash script?  I checked the environment in each instance, and 
in both cases LANG was set to en_US; in fact the only difference 
between the environment for the interactive bash shell and the script 
was the SHLVL variable.  Surely the behavior should at least be 
consistent if the environment variables are the same?
Comment 5 Hermann Schichl 2004-04-28 10:41:15 EDT
Is there any reason why [A-Z] or [a-z] are dependent on the LANG
setting? The LANG setting is useful in some aspects. However, if the
regular expressions are broken afterwards,...

BTW. [A-Z] also includes the lower case letters.
Comment 6 Pete Graner 2007-08-18 03:39:01 EDT
Bugzilla clean up. Closing. RHEL 2.1 is in maint mode. Fixed in later versions
of RHEL.

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