bug-bash
[Top][All Lists]
Advanced

[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):

address@hidden:~/tmp/bad$ echo $LANG
cs_CZ
address@hidden:~/tmp/bad$ export LANG=""
address@hidden:~/tmp/bad$ echo [a-z]*
Foo foo
address@hidden:~/tmp/bad$ export LANG="POSIX"
address@hidden:~/tmp/bad$ echo [a-z]*
foo
address@hidden:~/tmp/bad$ LANG="" bash
  address@hidden:~/tmp/bad$ echo [a-z]*
  foo
  address@hidden:~/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://address@hidden
ICQ: 66770334




reply via email to

[Prev in Thread] Current Thread [Next in Thread]