[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Incorrect behaviour in glob expansion in bash 2.05b.
From: |
Jakub Travnik |
Subject: |
Re: Incorrect behaviour in glob expansion in bash 2.05b. |
Date: |
Tue, 06 Jan 2004 14:51:25 +0100 (CET) |
Hello,
I have found the culprit. It is pretty brain dead behaviour depending
on locales (just unsetting LANG inside bash doesn't help):
jakub@jtra:~/tmp/bad$ echo $LANG
cs_CZ
jakub@jtra:~/tmp/bad$ export LANG=""
jakub@jtra:~/tmp/bad$ echo [a-z]*
Foo foo
jakub@jtra:~/tmp/bad$ export LANG="POSIX"
jakub@jtra:~/tmp/bad$ echo [a-z]*
foo
jakub@jtra:~/tmp/bad$ LANG="" bash
jakub@jtra:~/tmp/bad$ echo [a-z]*
foo
jakub@jtra:~/tmp/bad$ exit
(note: I have indented subshell)
Comment in fnmatch.c explains that:
/* We use strcoll(3) for range comparisons in bracket expressions,
even though it can have unwanted side effects in locales
other than POSIX or US. For instance, in the de locale, [A-Z] matches
all characters. */
Previous bash versions up to bash-2.04 have different comment:
/* We don't use strcoll(3) for range comparisons in bracket expressions,
even if we have it, since it can have unwanted side effects in locales
other than POSIX or US. For instance, in the de locale, [A-Z] matches
all characters. So, for ranges we use ASCII collation, and for
collating symbol equivalence we use strcoll(). The casts to int are
to handle tests that use unsigned chars. */
Which seems to be much reasonable.
Jakub Travnik
jabber://jtra@jabber.com
ICQ: 66770334