Dotaz: Je bash skutecne case-sensitive?

[Ladislav Benda]

Zdravim,

nedavno se mi prihodila nemila a neocekavana vec. Bash mi interpretoval regularni vyraz typu [A-Z]* jakoby nedelal rozdilu mezi velkymi a malymi pismeny. Problem se projevil o to neprijemneji, ze jsem se snazil smazat PRAVE a POUZE soubory zacinajici velkym pismenem: rm [A-Z]* Podle veskerych pravidel, kterymi se ridi interpretace regularnich vyrazu, by se melo stat presne to, co jsem zamyslel. Ovsem ve skutecnosti byl cely adresar dokonale promazan. Jak jsem nasledynym testovanim zjistil, muj bash se v tomto smyslu chova case-insensitive, tedy jako kdybych napsal rm [A-Z]* [a-z]*

Zkusil jsem si vypsat nastaveni shellu prikazem shopt. Ovsem promenne, ktere se toho mohly tykat, jsou nastaveny spravne:

nocaseglob off nocasematch off

Tento problem se opakuje vsude, kde je instalovana Fedora. Testoval jsem na techto systemech:

Linux 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:18:33 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)

Linux 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006 x86_64 x86_64 x86_64 GNU/Linux GNU bash, version 3.1.7(1)-release (x86_64-redhat-linux-gnu)

Linux 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 16:52:18 EST 2008 x86_64 x86_64 x86_64 GNU/Linux GNU bash, version 3.2.33(1)-release (x86_64-redhat-linux-gnu)

Odpovědi

[Filip Jirsák]

Výrazy typu [x-y] se interpretují podle aktuálního nastavení locale, a české řazení je case-insensitive (alespoň v prvním průchodu, který se asi pro řazení znaků používá).

[Filip Jirsák]

Ještě dodatek – doporučuje se v regulárních výrazech vyhýbat rozsahu [x-y] pro písmena abecedy, protože je to právě závislé na locale. Jediné rozumné použití je, pokud opravdu hledáte rozsah písmen podle nějaké abecedy, což v regulárním výrazu použijete asi jen výjimečně. Takže rozsah [x-y] je lepší používat jen pro symboly, které mají pevně dané pořadí podle ASCII, nebo používat znakové třídy.

Ostatně počítač udělat prozměnu přesně to, co jste mu napsal, ne co jste chtěl – vy jste mu napsal, že má hledat všechny soubory, které začínají písmeny od A do Z podle české abecedy (což jsou až na ž a Ž všechna česká písmena), ale přitom jste chtěl, aby našel všechny soubory začínající velkým písmenem, tedy třídou [:upper:].

[Petr Holík]

Musim vas opravit, ale v regulernich vyrazech je to presne obracene nez pisete. Alespon, co se tyka Perl kompatibilnich. A-Z je proste ABCDEF..XYZ at mate locale jekekoliv. Ale \w uz zavisi na nastaveni locale. Neplette prosim shellovou expanzi a regularni vyrazy, jsou to dve ruzne veci.

[Filip Jirsák]

Podle manuálové stránky je to v bashi tak, jak jsem to napsal – pořadí písmen se určuje podle nastaveného locale.

[Petr Holík]

To nikterak nepopiram, jenom tvrdim, ze v PCRE ( perl kompatibilni regulerni vyrazy) to tak neni.

router ~ # perl -e 'use locale; if ("a" =~ /[A-Z]/) {print "ano";} '
router ~ # perl -e 'if ("a" =~ /[A-Z]/) {print "ano";} '
router ~ # ( export LC_ALL=cs_CZ.UTF-8 ;export LANG=cz_CZ; perl -e 'use locale; if ("a" =~ /[A-Z]/) {print "ano";} ' )
router ~ #

jak videt nepodarilo se mi nikterak perl donutit, aby do A-Z pocital "a" protoze tam jednodusse nepatri :)

mimochodem pokud se na [A-Z]* budu divat striktne jako na regulerni vyraz, tak mu vyhovi naprosto vse vse(dokonce i Vase jmeno :) :

router ~ # perl -e 'use locale; if ("CokolAda.Linux^% Filip Jirsák" =~ /[A-Z]*/) {print "ano\n";} '
ano
router ~ #

jelikoz se ve vsech retezcich A-Z vykytuje libovolnekrat ( tedy i 0x)

[Ash]

Teda já myslím že Filipa Jirsáka učit regexp nemusíte :D Jinak ťuk ťuk, vítejte ve světě POSIX.2.

POSIX 1003.1:

bash$ man perl | grep POSIX
           perlbs2000          Perl notes for POSIX-BC BS2000
       ·   POSIX 1003.1 compliant library
           Described in POSIX.

POSIX 1003.2: man regexp

bash$ man sed | grep POSIX
       POSIX.2 BREs should be supported, but they aren’t completely because of

... If two characters in the list are separated by '-', this is shorthand for the full range of characters between those two (inclusive) in the collating sequence ... Ranges are very collating-sequence-dependent, and portable programs should avoid relying on them. ... The range does not refer to the native character set. For example, in the POSIX locale, [a-z] means all lowercase letters, even if they don't agree with the binary machine ordering. However, since many other locales do not collate in this manner, ranges should not be used in Strictly Conforming POSIX.2 applications.

Nebo úplně polopaticky tady: Regular Expressions

Range expressions must not be used in portable applications because their behaviour is dependent on the collating sequence. Ranges will be treated according to the current collating sequence, and include such characters that fall within the range based on that collating sequence, regardless of character values. This, however, means that the interpretation will differ depending on collating sequence. If, for instance, one collating sequence defines ä as a variant of a, while another defines it as a letter following z, then the expression [ä-z] is valid in the first language and invalid in the second. Asi by se našel lepší zdroj, ale příliš jsem nepátral, by mne nenapadlo že v dnešní době si ještě někdo myslí, že [A-Z] jsou velká písmena z ASCII ;)

[Ash]

Jinak samozřejmě, můžete tvrdit že v "perl kompatibilních reguléérních výrazech atd. atd.", ale pak prosím asi není chytré páchat škodu tím, že neopravujte někoho, kdo o perlu nemluvil, nýbrž mluvil o regulárních výrazech, že ano. Obzvlášť když rozšířené, moderní, a perl-kompatibilní regexp se tak často používají jako synonyma.

[Filip Jirsák]

Myslím, že gramatika popisující expanzi jmen souborů v bashi je také regulární jazyk, takže i tomu vzoru je možné říkat regulární výraz – pokud se tedy máme opravdu striktně držet termínů. Jinak máte samozřejmě pravdu, že expanze jmen souborů a „regulární výrazy“ v bashi jsou dvě odlišné věci. Ale nechtěl jsem to v odpovědi komplikovat, protože mi bylo jasné, že tazatel pouze potřeboval onen „expanzní výraz“ nějak označit.

Vaše demonstrace chování [A-Z] na perlu dokazuje jenom to, že se to takhle chová v nějaké verzi Perlu – PCRE je bohužel dost široký pojem, a v dokumentaci snad každé implementace PCRE najdete několik odstavečků o tom, jak se tahle konkrétní implementace liší od perlovských regulárních výrazů.

Jestli do [A-Z] patří „a“ nebo nepatří záleží na tom, jaké se použije řazení znaků. Vám připadá přirozené ASCII řazení, ovšem můžete mít výraz [A-ž], a tam už s ASCII nepochodíte. Mohl byste řadit podle kódu znaků aktuální znakové sady (např. Unicode; takhle to zřejmě dělá Perl), jenomže to zase výsledek nebude to, co byste očekával (např. do [A-ž] pak v Unicode patří i znaky jako paragraf, copyright, plusmínus, stupeň atd.) Jak už jsem psal – rozsah [?-?] je rozumné použít v případě, kdy se jedná o speciální znaky (ASCII 0x00 – 0x40), které jsou snad ve všech používaných znakových sadách a locale řazeny stejně. Na použití rozsahu s písmeny je potřeba si dát pozor a vždy ověřit, že se výraz nad různými locale a různými znakovými sadami chová tak, jak jsem chtěl.

[Petr Holik]

Dobry den,

ad odstavec 1) SOUHLAS :)

ad odstavec 2) Perl se standardne ve vsech verzich AFAIK( pokud neni pouzito "use locale;") chova tak, jako by bylo nastaveno LC_ALL=C. S skutecne nastaveni locale tise ignoruje. Proto jsem oponoval, ze v PELRu vyraz [a-z] obsahuje pouze abcdefgh...z a neni treba (alespon v perlu) se ho bat (pokud teda neuvedete direktivu use locale; pak se chovani perlu sjednoti s chovanim BASHe.)

ad odstavec 3) ano pokud date use locale; pak se skutecne zmeni i razeni znaku a rozsahy [?-?] v regexpech. To jakym zpusobem se to zmeni, a jak si to poradi s vicebytovym kodovanim bych neresil, protoze to dle meho nevedi ani tvurci perlu :) a dle mych zkusenosti to obcas zavisi i na pocasi v ugande.

Zaverem bych rekl, ze jsem se neumyslne trosku odklonil od tematu a zacal resit neco, co s puvodnim problemem nesouvisi. Priste si dam pozor :)

[Ash]

Nevím jak v regulérních, ale v regulárních výrazech je to jak bylo řečeno:

bash:
$ [[ "a" =~ ^[A-Z]$ ]] && echo je
je

sed:
pre>$ echo "a" | sed -r -e "s/[A-Z]/b/"
b

Na rozdíl od:

bash:
(LC_COLLATE=C; [[ "a" =~ ^[A-Z]$ ]] && echo je)

sed:
(LANG=C; echo "a" | sed -r -e "s/[A-Z]/b/")

Vhodnějším řešením je v obou případech zřejmě použít [:upper:].

[frEon]

nojo, ale tady je rec o beshi a ne o perlu. takze resime POSIX a ne pcre

[Ladislav Benda]

Diky za rychlou odpoved.

Cestinu nepouzivam, o jazyku jsem se nikde nezminoval a je mi tedy zahadou, proc vetsina odpovedi predpoklada cestinu. Pouzivam LANG=en_US.UTF-8 takze necekane chovani shellu podle me neni problem ceske znakove sady, jako spis UTF-8. Tolik jen pro uplnost.

Nastaveni locale bylo presne to, co bylo treba zmenit - stacilo export LC_COLLATE=C - od te doby ls [A-Z]* funguje normalne - resp. tak, jak bych cekal. Ovsem navrhovane ls [:upper:]* se chova jeste podivneji nez puvodni problem. To me ale uz netrapi... :) Jeste jednou diky.

[Michal Kubeček]

takze necekane chovani shellu podle me neni problem ceske znakove sady, jako spis UTF-8

Není to otázka ani znakové sady ani kódování. Je to otázka toho, jak je definované porovnávání ve zvoleném locale.

Ovsem navrhovane ls [:upper:]* se chova jeste podivneji nez puvodni problem.

Pochopitelně. Jak už řada odpovědí upozorňovala, masky používané při expanzi wildcards v shellu nejsou regulární výrazy a platí pro ně úplně jiná pravidla.

[Ash]

Čeština je dobrá pro demonstraci odlišného chování, ale jinak všichni zmiňovali že to závisí nastavení locale... Ta zmínka o vlivu UTF8 je poněkud mimo, říct že to závisí na nastavení locale je zcela dostačující, UTF8 do toho vůbec netahat, podle něj samotného se nic nepozná. Upřesnění že jde o C_COLLATE je vhodné, ale i to se tu objevilo mezi řádky a psal jsem ho jako demonstraci že regulární výrazy respektující POSIX.2 jsou na locales stejně závislé jako expanze v bashi. Možná jsem vás tím trochu zmátl, takže: v bashi lze používat regulární výrazy, tam funguje i [:upper:], ale na to jste se neptal, ptal jste se na expanzi v shellu, tam se dají použít různé "výrazy", závorky jako třeba [A-Z] nebo {a,b,c}, ale nejsou to ty "klasické" regexp, čili třeba s [:upper:] tam z tohoto důvodu nepochodíte.

[Ash]

P.S. Jinak to je tu zcela normální jev, že se linuxáci začnou přetahovat mezi sebou o vzájemné pravdy, začnou se řešit věci ohledně perlů, verzí POSIX, regulárních výrazů a původní dotaz na expanzi parametrů jde tak nějak mimo :D Kde bychom jinak k těm chytrostem přišli, když ne vzájemným popichováním, opravováním a upřesňováním :)

[Filip Jirsák]

původní dotaz na expanzi parametrů jde tak nějak mimo

Ono to nešlo tak úplně mimo původní dotaz. Informací, které by tazatele dovedly k tomu, aby si konečně otevřel man bash, tady bylo dostatek (ale zřejmě nás tu nebylo mnoho takových, kteří by si tu příslušnou část manuálu alespoň prolétli před tím, než napsali do diskuze). Až by tam našel, že podle dokumentace bash ty znakové třídy umí i u expanze souborů (alespoň v mé dokumentaci k 3.2.17 se o tom píše), ale jemu to nefunguje, a řešil by to dál v diskuzi, mohli jsme pokračovat v debatě k tématu.

[Filip Jirsák]

ptal jste se na expanzi v shellu, tam se dají použít různé "výrazy", závorky jako třeba [A-Z] nebo {a,b,c}, ale nejsou to ty "klasické" regexp, čili třeba s [:upper:] tam z tohoto důvodu nepochodíte

Nicméně důvod, proč s [:upper:] v bashi nebo zsh nepochodíte není ten, že je to expanze názvů souborů. Expanze názvů souborů umí (minimálně u těchto dvou shellů) i znakové třídy. Znakové třídy mají ale v tomto případě název např. [:upper:], a znaková třída se píše jako zástupný symbol do hranatých závorek (množina znaků) – takže ve výsledku musíte ty hranaté závorky mít zdvojené:

ls [[:upper:]]*

Ještě že je to v manuálu k zsh explicitně napsané, protože z popisu v manuálu bashe by mne to rozhodně netrklo…

[Ash]

To je dobré, tak to se musím přiznat že v tomto případě jsem byl mazi těmi, kteří do manuálu nenahlíželi :S a mlčky jsem předpokládal, že když to tazateli nešlo, tak že bash znakové třídy (při expanzi paramterů) neumí. Děkuji za upozornění.

[iKoulee]

Dobry den, ls [:upper:]* nefunguje protoze jde o vycet, pokud by jste chtel ziskat vysledek ktery jste ohlasoval na pocatku je treba pouzit.

ls [[:upper:]]*

[Ash]

A vy jste kde tento historický 690 dní starý dotaz vyhrabal?

[Michal Kubeček]

Člověk si hraje s formátováním a formulacemi a pak zjistí, že je "druhej"... :-( :-)

[Filip Jirsák]

To je zkrátka úděl precizních odpovědí

[Michal Kubeček]

1. Nejedná se o regulární výrazy, ale o expanzi wildcards.

2. Porovnávání řetězců, a tedy i význam masek s rozsahy závisí na locale. Např.:

mike@unicorn:~/x> touch a b c d e A B C D E
mike@unicorn:~/x> ls
A  a  B  b  C  c  D  d  E  e
mike@unicorn:~/x> echo $LANG
cs_CZ.UTF-8
mike@unicorn:~/x> ls [A-C]
A  a  B  b  C
mike@unicorn:~/x> export LC_ALL=C
mike@unicorn:~/x> ls [A-C]
A  B  C

Problém je v tom, že v cs_CZ.UTF-8 jsou písmena řazena tak, že malá jsou hned za příslušnými velkými, takže rozsah [A-Z] pokrývá celou abecedu kromě Ž, z a ž (případně z/Z s dalšími diakritickými znaménky).

Z toho plyne poučení: chcete-li, aby se skript choval deterministicky, nastavte hned na začátku LC_ALL na C.

[fxf]

Jenom pro zajímavost, já mám malá a velká písmenka opačně :)

pavel@wolfgang:/tmp/x $ touch a b c d e A B C D E
pavel@wolfgang:/tmp/x $ ls
a  A  b  B  c  C  d  D  e  E
pavel@wolfgang:/tmp/x $ ls [A-C]
A  b  B  c  C
pavel@wolfgang:/tmp/x $ echo $LANG
en_US.UTF-8
pavel@wolfgang:/tmp/x $ LC_ALL=cs_CZ.UTF-8 ls [A-C]
A  b  B  c  C

Debian unstable, libc6 a locales verze 2.7-9. Poměrně mě přakvapuje, že se to liší i podle konkrétní distribuce.

[Michal Kubeček]

Zajímavé. Jen bych ale pro úplnost upozornil, že v tom posledním příkladu má české locale vliv pouze na řazení souborů, ne na výběr (ten provádí shell).

[marbu]

Poznámka k terminologii: regulární výrazy a shellová expanze jmen souborů jsou dvě různé věci.

[Michal Kubeček]

Tak aspoň v něčem jsem byl ten rychlejší... :-)

[ee]

a co to bylo za souborovy system?

[Michal Kubeček]

Na tom v tomto případě vůbec nezáleží.

[R]

A z toho vyplyva ponaucenie: ked neviem, ako nieco funguje, tak si to najprv vyskusam. Specialne v pripade pouzitia prikazov typu rm.