Re: nocaseglob

[Tim Waugh]

On Tue, 2007-01-23 at 14:14 -0500, Chet Ramey wrote:
> The portable, standard way to perform character comparison using the
> current locale is strcoll().  If I can't get the same results using
> strcoll(), glibc is clearly doing something different internally.  (And
> there is no portable standard way to obtain the current collating sequence.
> The best you can do is sort sets of characters like I did.)

Character comparision, yes, but that is different to range matching.

> strcoll indicates that, in the "en_US" locale, `h' sorts between `A' and
> `Z'.  In the "C" locale, it does not.  This is consistent with the
> collating sequences I posted earlier.

Here is what Ulrich Drepper has to say on the matter (see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217359#c5):

"[...] The strcoll result has nothing whatsoever to do with
 the range match.  strcoll uses collation weights, ranges use
 collation sequence values, completely different concept.
 Not matching 'h' (note, lowercase) is correct since if you
 look at the locale definition you'll see that first all
 lower characters are described and then the uppercase.  So
 h is not in A-Z.  H (uppercase) of course is.

 From all I can see so far it's entirely bash's fault by not
 implementing globbing correctly.  bash really must use the
 fnmatch code from glibc itself."

Tim.
*/

signature.asc
Description: This is a digitally signed message part