Conversation started Sep 2, 2015 at 22:30.
Stéphane Chazelas
Stéphane Chazelas
Sep 2, 2015 22:30
@Gilles It's unclear to me. Looking at the code points to a _NL_COLLATE_COLLSEQWC which itself led me to lists.gnu.org/archive/html/bug-grep/2010-09/msg00076.html (the whole discussion is interesting, but it doesn't really tell exactly how that lookup table is derived from the LC_COLLATE data in the locale definitions).
The answer is probably in locale/programs/ld-collate.c in the glibc, but that's not easy to follow
Sorry lists.gnu.org/archive/html/bug-grep/2010-09/msg00070.html is the message in that discussion that mentions that look-up table (a hidden locale attribute on GNU systems).
I also found that GNU grep compiled --with-included-regex behaves differently as it's not able (or not willing) to query that table.
(is then based on codepoint like zsh)
Please let me know if you find out more about it.
Gilles
Gilles
@StéphaneChazelas interesting, but doesn't explain why two Debian squeeze machines behaved differently
I didn't spend a lot of time investigating because I always force LC_COLLATE=C anyway
Stéphane Chazelas
Stéphane Chazelas
Sep 2, 2015 23:21
@Gilles dunno. different package versions of grep or libc? locales not recompiled after a libc upgrade and different installation time?
Gilles
Gilles
@StéphaneChazelas I don't remember exactly, but I had machines of both types running Debian oldstable and stable, so it's probably not a matter of versions
I have chroots of every Debian version since potato. Each is pretty much unconfigured after debootstrap, but has the en_US locale generated.
I ran env -i PATH=/bin:/usr/bin LC_COLLATE=en_US grep -q '[a-z]' <<<B in each of these chroots
B is in [a-z] on potato, woody and squeeze. Not on sarge, etch, lenny, wheezy or jessie.
 
Conversation ended Sep 2, 2015 at 23:37.