Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 77349 - case sensitive filename globbing
Summary: case sensitive filename globbing
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
URL:
Whiteboard:
: 182497 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-05 17:24 UTC by Fabrice Bellet
Modified: 2007-04-18 16:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-11-05 17:31:21 UTC


Attachments (Terms of Use)

Description Fabrice Bellet 2002-11-05 17:24:27 UTC
Filename globbing has a strange behaviour, according to the nocaseglob shell
variable (bash-2.05a-13) :


bash-2.05a$ mkdir /tmp/test
bash-2.05a$ cd /tmp/test
bash-2.05a$ touch xx yy ZZ YY
bash-2.05a$ shopt -u nocaseglob
bash-2.05a$ echo [a-z]*
xx yy YY
bash-2.05a$ shopt -s nocaseglob
bash-2.05a$ echo [a-z]*
xx yy YY ZZ

--> I'd expect [a-z]* to glob to xx yy only when nocaseglob in unset.
Note : According to the Pattern Matching section of the bash manual, 
I checked that my LC_COLLATE has not an exotic value : it's unset.

Comment 1 Tim Waugh 2002-11-05 17:26:09 UTC
And 'locale' says?

Comment 2 Fabrice Bellet 2002-11-05 17:31:14 UTC
bash-2.05a$ locale
LANG=en_US
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=


Comment 3 Tim Waugh 2002-11-05 17:35:10 UTC
It is collating according to en_US rules.  You forgot to use 'LANG=C' if you
wanted C-locale collation.

Comment 4 Fabrice Bellet 2002-11-05 18:01:04 UTC
Setting C-locale didn't change the behaviour :

bash-2.05a$ export LANG=C
bash-2.05a$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=
bash-2.05a$ touch xx yy ZZ YY
bash-2.05a$ shopt -u nocaseglob
bash-2.05a$ echo [a-z]*
xx yy YY
bash-2.05a$ shopt -s nocaseglob
bash-2.05a$ echo [a-z]*
xx yy YY ZZ
bash-2.05a$ ls
YY  ZZ  xx  yy

I'd say it looks like a boundary problem when globbing [a-z], because if I
substitute the filename ZZ with another one in uppercase, strictly
included in the a-z range, this filename is globbed, independantly of
the value of the 'nocaseglob' option :

 bash-2.05a$ rm ZZ
bash-2.05a$ touch XX
bash-2.05a$ shopt -u nocaseglob
bash-2.05a$ echo [a-z]*
xx XX yy YY
bash-2.05a$ shopt -s nocaseglob
bash-2.05a$ echo [a-z]*
xx XX yy YY
bash-2.05a$ ls
XX  YY  xx  yy

Did I forget something else ? It looks strange and unexpected to me.

Comment 5 Fabrice Bellet 2002-11-05 18:06:31 UTC
By the way, [[:upper:]] and [[:lower:]] show me an expected behaviour with the C
locale :

bash-2.05a$ ls -l
total 0
-rw-r--r--    1 bellet   users           0 Nov  5 18:49 XX
-rw-r--r--    1 bellet   users           0 Nov  5 18:47 YY
-rw-r--r--    1 bellet   users           0 Nov  5 18:47 xx
-rw-r--r--    1 bellet   users           0 Nov  5 18:47 yy
bash-2.05a$ shopt -s nocaseglob
bash-2.05a$ echo [[:lower:]]*
xx XX yy YY
bash-2.05a$ echo [[:upper:]]*
[[:upper:]]*
bash-2.05a$ shopt -u nocaseglob
bash-2.05a$ echo [[:lower:]]*
xx yy
bash-2.05a$ echo [[:upper:]]*
XX YY


Comment 6 Tim Waugh 2002-11-05 18:30:53 UTC
Then perhaps you are seeing bug #74701, where changing the LANG shell variable
doesn't call setlocale?  Try 'LANG=C bash'.

Comment 7 Fabrice Bellet 2002-11-05 18:43:57 UTC
Yes, it works in this case. Thanks and sorry for the false alarm :-)

Comment 8 Tim Waugh 2006-02-22 23:01:33 UTC
*** Bug 182497 has been marked as a duplicate of this bug. ***


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