Roman Rakus wrote:
Matthew Woehlke wrote:
Roman Rakus wrote:
When trying to match files [a-z] bash find files A-Z, depending on
LC_COLLATE.
The mistake is in usage of strcoll()/wcscoll(). It has nothing to do
with ranges. Instead should be used fnmatch().
I can try to change this behavior. Or is this planned/done for next
bash release?
How is that incorrect? Depending on LC_COLLATE, the range '[a-d]'
might mean 'abcd', 'aAbBcCd', 'aAàÀáÁâÂãÃäÄåÅæÆbBcCçÇd', etc.
If you want C semantics, use 'LC_COLLATE=C'.
I think in range [a-d] shouldn't be any upper char. These are 2
different things. Collate orders and range match. Try to use glob and
you will see difference.
This is really not good behavior of bash.
I have looked at
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03_05
and there is written:
7. In the POSIX locale, a range expression represents the set of
collating elements that fall between two elements in the collation
sequence, inclusive. In other locales, a range expression has
unspecified behavior: strictly conforming applications shall not rely on
whether the range expression is valid, or on the set of collating
elements matched. A range expression shall be expressed as the starting
point and the ending point separated by a hyphen ( '-' ).
So if I understand it well, the behavior of bash isn't bad. But there is
question, if this behavior we would like to change or not? I think more
predictable is glob()-like behavior then strcoll().
begin:vcard
fn:Roman Rakus
n:Rakus;Roman
org:Red Hat;BaseOS
adr:;;;Brno;;;Czech Republic
email;internet:[EMAIL PROTECTED]
title:Associate software engineer
tel;cell:+420 774 891 861
x-mozilla-html:FALSE
version:2.1
end:vcard
