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
_______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
