Re: range match works incorrect

[Roman Rakus]

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().

rrakus.vcf
Description: Vcard