Re: How to NOT allow LC_COLLATE to corrupt globbing ???

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 7,  2:44pm, Stucki wrote:
} Subject: How to NOT allow LC_COLLATE to corrupt globbing ???
}
} Once again I nearly was bitten by an Environment containing:
} export LC_COLLATE=de
} 
} Then doing 'rm *[A-Z]*' on a Sun is really doing 'rm *'
} as there is no difference between upper and lower case
} in the german collating sequence.

When we discussed this earlier this year, Zoltan concluded in

http://www.zsh.org/mla/workers/1998/msg00551.html

that GNU regexp and bash don't use the collating sequence in character
ranges, and that it's therefore probably OK for zsh not to either.  Hey,
Tim, any chance you can try ksh in some other language environment to
see if it collates character ranges?

} So now I'd like to ***compile*** my zsh in a way that makes sure
} I *always* use the standard collating sequence like LC_COLLATE=C
} (or may be LC_COLLATE=us).
} 
} (changing 'config.h' *after* running 'configure'
}  to contain '#define HAVE_LOCALE_H 0' did *not* help!)

That's because glob.c calls strcoll() if HAVE_STRCOLL is defined, whether
or not locale.h is present or any other locale macros are defined.  So if
the library strcoll() believes LC_COLLATE, you're going to get collating
behavior.  Contrariwise, if you #undef HAVE_STRCOLL you'll get the rest
of the locale-specific behavior without getting collating sequences.

There are other places where HAVE_STRCOLL is used and might be desirable,
though, so it would really be best to make a decision on glob.c and either
remove the HAVE_STRCOLL code or make it part of the appropriate emulation.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com