squeeze + utf8 + grep = meglepetés

Debian GNU/Linux

mgergi@xx:~$ export LANG=C           ; echo "ab" | grep "[A-Z]"
mgergi@xx:~$ export LANG=en_US       ; echo "ab" | grep "[A-Z]"
mgergi@xx:~$ export LANG=en_US.UTF-8 ; echo "ab" | grep "[A-Z]"
ab
mgergi@xx:~$

Ez meg mi, és miért, és hogyan? Etch és Lenny alatt rendesen működik, és a wheezy-ben is ismét jó.

Ok, ki tudom kerülni, a [[:upper:]] és a perl regexp is jól működik, de miért kell átírni 20 éve működő scripteket? A Linuxos világ nem erről szólt eddig...


mgergi@xx:~$ export LANG=en_US.UTF-8 ; echo "ab" | grep "[[:upper:]]"
mgergi@xx:~$ export LANG=en_US.UTF-8 ; echo "ab" | grep -P "[A-Z]"
mgergi@xx:~$

2273 megtekintés

"A Linuxos világ nem erről szólt eddig..."
De. Lasd meg: systemd.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

0 szavazat

A hozzászóláshoz be kell jelentkezni

Semmi meglepetés. A bracket-kifejezés mindig is rendezési elemekből állt, következésképpen locale függő. Az

en_US.UTF-8

rendezési locale-kategória (LC_COLLATE) történetesen nem tesz különbséget a kis és nagybetűk között. (Például a

és

string-eket

,

sorrendbe rakja, míg a POSIX locale fordítva.) Ennek megfelelően a megadott tartományba a kisbetűk is beleesnek, ezért adódik az illeszkedés. (Egyébként a range expression-ök a POSIX locale-en kívül nincsenek is specifikálva.)

Pontosabban: a bemenetben az "a" és az "A" egyazon collating element-nek felelnek meg, amely collating element-et pedig megadtál a tartományban.

de miért kell átírni 20 éve működő scripteket

Már húsz éve is rosszak (pontatlanok) voltak, de csak most derült ki. Írd ezt a script-ben: