Hlavní navigace

Hrátky z řádky: pomocné soubory a zamykání

7. 4. 2008
Doba čtení: 4 minuty

Sdílet

Opět se setkáváme u pravidelné pondělní dávky tipů a triků z černé řádky. V dnešním díle se podíváme na problém pomocných (nebo chtete-li dočasných) souborů a zamykání souborů. Popíšeme si, jak správně vyrobit pomocný soubor, jak se naopak obejít bez pomocných souborů a také jak na zamykání souborů v bashi.

Jak správně vyrobit pomocný soubor

Pomocné soubory pro mezivýsledky při skriptování budete potřebovat často. Není ale strašlivější chyby, než chyby zaviněné kolizí dvou skriptů, které si navzájem přepisují pomocné soubory. Takovou chybu totiž zreprodukujete jedině neskutečně šťastnou náhodou, že se skripty střetnou ve stejnou chvíli i příště. Studium trosek po kolizi je obtížností srovnatelné s hledáním příčiny pádu letadla, nehledě na to, že slušný skript pomocné soubory před skončením smaže. V nepřátelském prostředí více uživatelů (tj. vlastně vždycky) se navíc podobné kolize užívají k získání neoprávněného přístupu.

Nejhloupější varianta spoléhá, že skript nikdy nepoběží víckrát a že pevné jméno nepoužije současně nikdo jiný:

pomocny=/tmp/moje-specialni-jmeno

Druhá nejlínější varianta do jména souboru zakomponovává číslo procesu (speciální proměnná $$). Stejný skript tedy může současně běžet víckrát a kolize nenastane (pokud do stejného adresáře nezapisuje víc počítačů, pak by samozřejmě i stejné číslo procesu mohlo být užito víckrát):

pomocny=/tmp/pom.$$

Mnohem lepší je ale nechat např. prográmkem mktemp vyrobit jméno zaručeně unikátní, koncová X totiž vybere tak, aby konfliktu zamezil:

pomocny=`mktemp /tmp/pomocny.XXXXXX` || exit 1

Program mktemp můžete též užít k vyrobení pomocného adresáře (parametr -d) pro všechny pomocné soubory pohromadě.

Jak se obejít bez pomocných souborů: Pojmenované roury

S pomocnými soubory nemáte práci navíc jen vy, ale i systém. Efektivnější je se jim úplně vyhnout pomocí rour. Pokud kýžený program trvá na tom, že musí pracovat se souborem, nebo pokud potřebujete „několik rour naráz“, můžete použít pojmenované roury.

Pojmenovaná roura navenek vypadá jako soubor, má jméno v adresářové struktuře. Pokud jej ale nějaký proces zkusí číst, bude zablokován, dokud se jiný proces nepokusí do roury zapisovat, a naopak. Až se producent a konzument sejdou, data protečou rourou, aniž by se ukládala na disk. Pojmenované roury můžete vyrobit příkazem mkfifo (pak ale musíte bojovat s volbou názvu souboru):

mkfifo roura
date > roura &
# spouštíme na pozadí, abychom dostali zpátky konzoli
cat < roura
rm roura # pro pořádek, pokud rouru už nebudeme potřebovat

V jednoduchých situacích v bashi postačí tzv. Process Substitution:

Takto vnějšímu programu předáte název „souboru“, který bude obsahovat to, co vyrobí vnitřní program na svůj stdout:

vnejsi <(vnitrni)
# např. upovídaná analogie k: "hostname; date"
head <(hostname) <(date)

Analogicky můžete nechat připravit soubor pro „odtok“ dat rovnou na stdin vnitřního programu:

vnejsi >(vnitrni)

Here-documents, víceřádkové echo

Jako dodatek k předchozím dílům uveďme, že ve skriptu můžete užít tzv. here-document, tj. přisměrovat data přímo z těla skriptu na stdin nějakého programu. Zde je víceřádková obdoba echa:

cat  << KONEC
řádek jedna
řádek dva
KONEC

Koncové slovo si volíte sami. Pokud jej uvedete v apostrofech, bude i opisovaný text brán doslova, bez expanze proměnných ap. Chcete-li pro přehlednost text či koncové slovo odsadit, použijte „ <<- “ místo „ << “, aby bash počáteční tabulátory ignoroval.

Zamykání souborů v bashi

Pomocné soubory děláme, chceme-li zamezit náhodné kolizi a komunikaci mezi procesy vůbec. Občas ale potřebujeme, aby spolu dva skripty komunikovaly přes dohodnutý soubor. I v takovém případě je třeba zabránit kolizi (kdy např. jeden program už čte to, co druhý ještě nedopsal). Pro tento účel je možné soubory zamykat. V bashi nemáte nad zamykáním plnou kontrolu, můžete ale aspoň použít pomůcku lockfile (součástí distribuce procmailu) a vedle citlivého souboru vyrobit navíc soubor zámku. Pomůcka lockfile před vyrobením zámku totiž ověří, jestli už na daném místě zámek není, a pokud ano, zablokuje se, dokud někdo (typicky původní autor) zámek neodstraní:

sdileny_soubor=/cokoli/kdekoli
lockfile $sdileny_soubor.lock
# teď mi žádný slušný kolega nepoleze do zelí
echo "byl jsem zde" > $sdileny_soubor
rm -f $sdileny_soubor.lock # k odemčení stačí zámek smazat
# a teď zas může soubor měnit někdo jiný, já jsem odemkl

Zámky jsou bohužel jen dobrovolné a informativní. Různé programy užívají různé mechanismy zamykání, např. jsme si mohli jenom jinak zvolit příponu „ .lock “ nebo prostě lockfile zapomenout zavolat. (Pověstný je v tomto směru rozdíl mezi editory vim a emacs, navzájem si mohou omylem měnit soubory pod rukama.) I přesto se pečlivým užíváním zámků můžete aspoň sami před sebou poměrně dobře chránit.

Mírné povědomí o technice „zamykání souborů“ pomocí dodatečných souborů se hodí i pro případy nenadálých pádů různých programů (např. firefox). Občas totiž padající program nestihne zámek odstranit a příště se odmítne spustit (s tím, že „už přece jednou spuštěn je“). Často postačí (najít a) smazat vhodný soubor zámku ručně.

CS24 tip temata

Za domácí cvičení můžete zkusit pomůcku lockfile naprogramovat sami v bashi, úplně snadné to ale nebude, protože prosté „ while [ ! -e file.lock ]; do sleep 5; done; touch file.lock “ nefunguje. Dva skripty se totiž mohou potkat tak, že oběma se bude ještě zdát, že soubor zámku neexistuje, a oba „zamknou současně“. Mne napadá použít přesměrování s nastavením noclobber (viz manuálová stránka bashe), ale třeba v diskusi navrhnete něco lepšího.

Na závěr připomínám výzvu z diskuse: Máte vlastní sbírku tipů pro příkazovou řádku? Nechcete se s námi podělit o své perly z ~/.bash_history? Prostor tohoto seriálu čeká i na díly od vás. Napište do redakce nebo nám, stávajícím autorům. Rádi vás mezi sebou přivítáme.

Autor článku