Unixové nástroje – 6 (touch, du, file)

22. 12. 2009 | David Watzke | Návody | 12749×

V tomto díle si představíme nástroj pro změnu časových atributů u souborů – touch, dále program pro výpis velikosti souborů – du a nakonec příkaz pro zjištění typu souborů – file.

Obsah

• touch
• du
• file

touch

Název příkazu touch je anglické slovo, které znamená dotek – tzn. v podstatě „sahá“ na soubory (a adresáře), což sedí; slouží totiž ke změně času posledního přístupu (atime) a poslední změny (mtime) souboru. Vedlejší, ale často využívanou funkcí je vytváření prázdných souborů.

Program se poprvé objevil v systému AT&T UNIX verze 7. GNU implementace je dodávaná v balíku coreutils, který obsahuje spoustu základních utilit.

Základní použití vypadá následovně:

# pokud „soubor1“ neexistuje, bude vytvořen (prázdný);
# pokud existuje, bude změněn jeho atribut atime a mtime na aktuální čas
touch soubor1

Proč by někdo chtěl měnit čas poslední změny souboru? Některé programy tento údaj využívají a ovlivňuje to jejich chování. Například make, což je program sloužící ke spuštění sekvence příkazů pro dosažení určitého cíle podle souboru s pravidly, jej využívá k tomu, aby při opětovném spuštění zjistil, zda už určité kroky dříve neprovedl, aby je případně mohl přeskočit a pokračovat dále.

Teď, když už víme, jaký má příkaz smysl, si popíšeme přepínače, jejichž implementaci vyžaduje standard.

Přepínač	Význam
-a	Změní pouze čas posledního přístupu (atime).
-c	Nevytvoří prázdný soubor, pokud daný neexistuje. Nevypíše chybu.
-m	Změní pouze čas poslední změny (mtime).
-r x	Použije odpovídající časy souboru „x“ místo aktuálního času.
-t y	Použije čas „y“ místo aktuálního času. Viz níže.

Předvedeme si to na ukázkách:

# totéž jako samotné: touch soubor2
touch -am soubor2

# změní pouze čas poslední změny na aktuální čas
touch -m soubor3 soubor4

# změní čas posledního přístupu k souboru „cil“ na čas
# posledního přístupu k souboru „reference“
touch -a -r "reference" "cil"

Jak jsem v tabulce s přepínači naznačil, přepínač -t umožňuje zadat vlastní čas. Ten se zadává číselnou hodnotou ve tvaru [[CC]YY]MMDDhhmm[.SS], kde hranaté závorky značí volitelnost. Co jednotlivé znaky znamenají? Postupně od nejdelší po nejkratší časovou jednotku to je století – CC, rok – YY, měsíc – MM, den – DD, hodina – hh, minuta – mm, sekunda – SS. Nezadáte-li století (CC), pro roky (YY) 00 až 68 je implicitní hodnota 20 a pro roky 69 až 99 hodnota 19. (Výchozí století se v budoucím standardu změní.) Nezadáte-li ani rok, předpokládá se aktuální. Sekundy mají rozsah 0 až 60 (a ne 0 až 59 – kvůli přestupným sekundám); zadáte-li SS hodnotu 60, chování bude záviset na proměnné prostředí TZ.

# nastaví atime a mtime na 1. 12. 2009, 15:25:35
touch -t 200912011525.35 "../soubor 5.txt"

# nastaví atime na 12. 4. 00:00:00 (letošního roku)
touch -a -t 04120000 "/adresar 1/soubor 6.txt"

# nastaví mtime na 20. 7. 1991, 13:15:00
touch -mc -t 9107201315 "/home/dave"

GNU verze navíc poskytuje přepínač -d (--date), který umožňuje zadat datum v čitelnější podobě, například „2004-02-29 16:21:42“ nebo dokonce relativně: „next Thursday“ (příští čtvrtek).

---

du

Program du slouží k odhadu zabraného místa danými soubory či adresáři. Název vychází z anglického výrazu disk usage, což znamená využití disku. Utilita se poprvé objevila v AT&T UNIX v1.

Základní použití vypadá takto:

# vypíše velikost všech souborů a adresářů v pracovním adresáři
du

# vypíše velikost všech souborů a adresářů v adresáři „/var“
du /var

# totéž pro „soubor1“ a „soubor2“
du "soubor1" "soubor2"

Program du počítá pouze prostor alokovaný existujícími soubory a adresáři, což je důvodem pro skutečnost, že může zobrazovat jiné hodnoty, než třeba příkaz df, který zmíním v některém z dalších dílů.

Výchozí chování programu je takové, že nenásleduje symbolické odkazy a když na ně narazí, počítá pouze velikost odkazu, nikoliv odkazovaného souboru. To lze ovlivnit správným přepínačem. V takovém případě se odkazovaný soubor počítá pouze jednou, i když je na něj odkazováno vícekrát. Popíšeme si standardní přepínače.

Přepínač	Význam
-a	Kromě průběžných informací o velikosti adresářů se budou vypisovat i informace o velikosti všech jednotlivých souborů.
-H	Následuje explicitně zadané symlinky zadané jako argument.
-k	Vypíše velikosti jako násobky 1024 bytů (místo výchozích 512 B).
-L	Následuje všechny symbolické odkazy.
-s	Zakáže detailní výpis s velikostmi jednotlivých podadresářů. Vypíše pouze celkové velikosti.
-x	Aktivuje procházení adresářové struktury pouze v rámci souborového systému daných adresářů.

BSD a GNU verze příkazu mají užitečný přepínač -h, který vypisuje velikosti v rozumných jednotkách tak, aby byl výpis přehlednější pro uživatele.

GNU implementace má přepínač -c, který zajistí výpis celkové velikosti všech zadaných souborů a adresářů.

# vypíše celkovou velikost všech položek v adresáři
du -sh
2,1M    .

# vypíše velikosti daných adresářů a nakonec i součet
du -chs ../data/ ../tmp/
59G     ../data/
474M    ../tmp/
60G     total

# následuje odkazy, což je důvodem pro větší velikost
du -hsL ../tmp/
5,9G    ../tmp/

---

file

Program file slouží ke zjištění typu souboru. Název vychází z anglického slova file, což znamená „soubor“.

Poprvé se tento příkaz objevil v Research Unix 4 a poté byl v System V značně přepracován (především se informace o typech přesunuly z binárky do textového souboru). Většina distribucí GNU/Linuxu a BSD (ne-li všechny) používá open-source reimplementaci od Ian Darwina, kterou tento vývojář napsal v roce 1986 a od té doby do ní přispěla spousta dalších lidí.

Základní použití vypadá takto:

$ file nejaka_empetrojka.mp3
nejaka_empetrojka.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo

Neexistuje žádná jediná správná cesta jak zjistit typ souboru, proto se musí provádět různé testy a podobně. Program postupuje takto (a cyklus se zastaví tehdy, když dojde k výsledku):

1. Pokud soubor neexistuje, nelze číst nebo nelze zjistit jeho stav, příkaz vypíše, že byl soubor zpracován, ale typ nebylo možné zjistit.
2. Pokud program narazí na něco, co není běžný soubor, vypíše jeho typ. Mezi rozeznávané typy patří adresáře, pojmenované roury (FIFO), sockety, bloková/znaková zařízení. Symbolický odkaz se ve výchozím režimu bere jako soubor, na který symlink odkazuje (viz přepínače -h a -i níže).
3. Pokud má soubor nulovou délku, je identifikován jako prázdný soubor.
4. Program prozkoumá počátek souboru a odhadne jeho typ na základě patřičných testů (podle hlavičky).
5. Program prozkoumá celý soubor a odhadne jeho typ na základě patřičných testů (podle obsahu).
6. Pokud program nedojde k výsledku ani v předchozím bodě, je soubor identifikován jako datový soubor.

Standard vyžaduje implementaci následujících přepínačů:

Přepínač	Význam
-d	Použije na soubor všechny výchozí systémové testy. Toto je výchozí chování, když není zadán přepínač -M nebo -m.
-h	Když program narazí na symlink, nenásleduje jej, ale indentifikuje ho jako symbolický odkaz. Totéž se stane, když -h zadané není a program narazí na symlink odkazující na neexistující umístění.
-i	Narazí-li program na běžný soubor, nebude jej dále testovat na konkrétní typ.
-M x	Použije daný soubor s testy (x) pro testování hlaviček souborů. Žádné ostatní testy se nepoužijí, pokud zároveň není zadán přepínač -d.
-m y	Použije daný soubor s testy (y) pro testování hlaviček souborů.

Je-li přepínač -m zadán bez přepínače -d nebo -M, použijí se výchozí systémové testy hlaviček hned po testech z daného souboru:

# identifikuje soubor.exe podle hlavičky pomocí testů ze soubor_magic
file -M soubor_magic "soubor.exe"

# základní identifikace
file -i kvadro1.jpg
kvadro1.jpg: image/jpeg; charset=binary

# výchozí identifikace
file kvadro1.jpg
kvadro1.jpg: JPEG image data, JFIF standard 1.01

Projekt GnuWin32 poskytuje port tohoto programu (a dalších GNU utilit) pro Windows.

       

Komentáře

[honza]

kritika musi byt: to povidani o find je skutecne vice nez ubohe. Daly by se o tom napsat disertace, ale pan autor se zmuze jen na par nicotnych radek.

Jestlize si takhle predstavuje redakce budoucnost abicka, tak potes panbuh.

[David Watzke]

find? Myslíš file? Nic ti nebrání mě tu doplnit.

[Bill Gates]

e? file - find - neprisel jste zrovna z hospody .. ? :)

[Robert Krátký]

Daly by se o tom napsat disertace, ale pan autor se zmuze jen na par nicotnych radek.

Jenže cílem není disertace. Cílem je právě těch pár řádků, stejně jako v případě popisu dalších příkazů. Stručné představení a shrnutí možností. Ale tys to asi ani nečetl, co?

[x]

Od toho je tady snad tech par radku v man strankach v sekci Description.

[disorder]

Příloha:

• facepalmev.gif (0 bytů)

a cielom je clanok o touch, du a file? vid priloha

[martin]

kritika musi byt:

Proc, proboha?

Clanek slibuje predstaveni prikazu a ne jejich podrobne pitvani. To taky plni, takze pokud jde o mne, plna spokojenost.

[lok]

Jiste, je to jen par radek, ale myslim ze jako uvod do pouziti prikazu jsou naprosto dostacujici. Takze ja jsem s clankem spokojen.

[Tomáš Pelc]

Výborný článek/seriál - děkuji.

[petr_p]

Neexistuje žádná jediná správná cesta jak zjistit typ souboru,

Existuje. Stačí, aby autor (uživatel, program) tuto informaci k souboru přidal:

$ getfattr --dump /tmp/l10n.xhtml.gz 
getfattr: Removing leading '/' from absolute path names
# file: tmp/l10n.xhtml.gz
user.mime_encoding="x-gzip"
user.mime_type="application/xhtml+xml"

Bohužel nikdo si na rozšířené atributy ani nevzpomene. Ani desktopová prostředí, která tento koncept standardizovala. Na Mac OS X se prý metadata souborů využívají zcela běžně.

[tsLnox]

Existuje. Stačí, aby autor (uživatel, program) tuto informaci k souboru přidal:

A že je to ta jediná správná cesta říká kdo? Já tu větu "Neexistuje žádná jediná správná cesta jak zjistit typ souboru" pochopil tak, že existuje více správných cest, jak zjistit typ souboru.

[Filip Jirsák]

Je několik cest, jak odhadnout typ souboru. Typ souboru se nemá zjišťovat, ale určovat – a určuje jej pochopitelně autor. Je smutné, že s typem souboru určeným autorem se dá pracovat všude možně, jenom při uložení na disk se většinou tahle informace zahodí. Bylo by hezké, kdyby OSS šel v tomhle příkladem a začal používat standardy, které si sám nadefinoval (jak píše Petr výše).

[zoul]

Na Mac OS X se prý metadata souborů využívají zcela běžně.

Na Maccích je to v poslední době složité. Původní Mac OS používal pro určení typu souboru jakýsi čtyřznakový kód. Pak se myslím s přechodem na OS X začaly používat přípony souborů a konečně existuje ještě takzvaný Uniform Type Identifier, což je klasický otočený doménový zápis à la com.apple.itunes. Přípony jsou ošklivé, ale metadata na druhou stranu dost špatně přežívají jakýkoliv transport, například na cizí souborové systémy nebo po síti.

[Filip Jirsák]

Metadata transport po síti zvládají dobře (např. protokol HTTP má hlavičku Content-Type, MIME typ souboru také přenáší), problém je právě v tom uložení na disku.

[Michal Kubeček]

HTTP ano, ale co jiné - FTP, SCP/SFTP, NFS, CIFS… ?

[Filip Jirsák]

Poměřoval jsem to objemem přenesených dat. U CIFS to nikoho nezajímá, protože typ souborů do metadat neukládá ani operační systém, který je s tímto protokolem spojen. A zbytek je okrajová záležitost (ano, vím, že jak pro koho). Navíc ty zmiňované protokoly se většinou používají pro přenos souborů ze souborového systému na souborový systém, takže je potřeba stejně mít informace o typu souboru uložené někde v tom souborovém systému. U toho HTTP jsou metadata o souboru často někde v databázi, kde je snadné udržovat i typ.

[zoul]

V praxi bys stejně musel důsledně převádět mezi metadaty uloženými někde bokem a „metadaty“ v příponě souboru, ne? To je velice ošemetná záležitost z pohledu zpětné kompatibility a výměny dat. Pokud tahle konverze byť třeba jen v titěrném procentu případů selže, někdo dostane data, která bez solidnějších znalostí počítačů nebude moct použít. To je naprosto nepřípustná situace.

Příklad: Vytvořím archiv Foo, bez přípony, a jako content-type uložím třeba application/x-zip-compressed (nevím, jestli je to správně, nesejde na tom). Když ho načtu třeba jako přílohu do běžného poštovního klienta, který nebude mít podporu pro metadata, jak se klient dozví typ souboru? Podobně u příjemce: Příjde mi příloha nazvaná Foo s content-type zip. Pokud místní operační systém nepodporuje metadata, klient by musel vědět, že má soubor uložit s příponou .zip.

[Filip Jirsák]

Nic vám přece nebrání vedle metadat dál používat přípony souboru. Kdo umí použít metadata, použije ta, kdo ne, použije alespoň příponu. Ostatně, třeba na webu to takhle funguje dávno, a nezdá se, že by to byl problém. Navíc problémy s pojmenováním souborů jsou běžné i dnes. Zpětná kompatibilita je sice hezká věc, ale neznamená to zastavení jakéhokoli rozvoje. To bychom ještě dneska používali 7bitové kódování a znaky anglické abecedy, protože co když náhodou někdo nebude umět zpracovat text s diakritiky nebo dokonce Unicode.

[default]

Metadata jsou fajn, ale spousta programů s nimi neumí pracovat. Třeba SubVersion. Když si vyexportuju třeba ilustrace s příponou .ai, tak mi je otevírá Preview namísto Illistratoru. Tato informace byla původně ve working-copy v metadatech a SubVersion se na to jaksi vytento. Nejen díky tomuto, ale i díky nepodpoře paznaků v názvech souborů, nelze verzovat uživatelská ikona adresáře. Takže na řadu přichází řečnická otázka, zda je SubVersion opravdu verzovací systém, když půlku dat zahodí nebo odmítne?

co když náhodou někdo nebude umět zpracovat text s diakritiky nebo dokonce Unicode

Takových je tu spousta. Aspoň soudě z diskuzí o diakritice.

[zoul]

Nic vám přece nebrání vedle metadat dál používat přípony souboru.

Na to jsem narážel: Pokud musím kvůli spolupráci s ostatními stejně používat přípony, můžu se na metadata zrovna vykašlat.

[zoul]

(Abychom si rozuměli: Metadata o typu souboru jsou dobrá, jsem všema deseti pro. Jen říkám, že v praxi stejně dostává přednost přípona souboru, takže není divu, že se do implementace metadat nikdo dvakrát nehrne.)

[Filip Jirsák]

Jenže to je začarovaný kruh – nikdo je neimplementuje, protože je nikdo nepoužívá, a nikdo je nepoužívá, protože nikde nejsou implementovaná. Naštěstí se už podařilo pár takových kruhů rozetnout.

[petr_p]

Sémanticky to je problém, ale syntakticky ne, protože rozšířené atributy zvládá většina souborových systémů (včetně VFAT) i protokolů na jejich přenos (SFTP, NFS, CIFS ano).

[Qaxi]

nějaký zdroj ???

[kyknos]

Na klasickych Macich (OS X neznam) byly ty kody dva - jeden (TYPE) oznacoval typ souboru (misto pripony), druhy (CREATOR) aplikaci, se kterou je soubor asociovany (casto ta, ktera soubor naposledy ulozila, uzivatel to vsak samozrejme mohl menit). Vysledne chovani bylo takove, ze napriklad obrazek upravovany photoshopem se otevrel k dalsim editacim opet ve photoshopu , obrazek upravovany painterem (simulace realnych vytvarnych technik) se opet otevrel v painteru a porno se otevrelo v prohlizeci porna, a to vse presto, ze mohly byt ve stejnem formatu (pripadne i se stejnou priponou). Teprve pokud asociovana aplikace nebyla k dispozici, otevrel se soubor v aplikaci, ktera byla pro dany typ souboru nastavena jako vychozi. Stejne tak ikony souboru zavisely na teto asociaci - obrazky patrici k nejakemu photoshopovemu projektu mely ikonku photoshopackou zatimco porno mohlo mit pornoikonku. Bylo to docela prijemne chovani, ktere mi po prechodu na PC dlouho chybelo.

Navic pokud vim Apple oba kody nejak centralne registroval a vyvojarum prideloval, aby byly jedinecne, v dnesni dobe zivelneho vyvoje si to moc neumim predstavit.

Nevyhoda byla ta, ze v podstate nebylo mozne stahnout z Internetu aplikaci a hned ji spustit (bezpecnostne to asi byla ve srovnani s dos/win vyhoda) - soubor jednak nemel spravny TYPE/CREATOR (plnici stejnou funkci jako pripona .exe v dosu - tohle by znaly uzivatel jeste mohl napravit), ale aplikace obvykla prisla o spoustu dalsich dat ulozenych v tzv RESOURCE fork (podporovany jen macovskym filesystemem), ikony, struktury menu, dialogy a spousta dalsich veci, casto vcetne vlastniho kodu. Takze pres sit ci nepratelske souborove systemy sly programy prenaset jen zabalene v archivu podporujicim tyto specialni vlastnosti.

Pruser nastal, kdyz clovek v systemu nemel patricny program pro rozbalovani techto archivu - nebyl standardni soucasti systemu a stahnout sel pochopitelne jen zabaleny v archivu :) To pak byla navsteva u kamarada nebo (tehdy drahy) zapadacky casopis s cedeckem s popularnimi programy k nezaplaceni...

[rich]

ale treba ja na svem UNIXU (HP-UX) nemam ten "tvuj" getfattr

[Frekvence]

To je stejný nesmysl, jak určování podle přípony (i když musím uznat, že informací je v metadatech více a využitelnějších). Já potřebuji vědět co je fyzicky uvnitř souboru, ne co by v něm mělo být.

[funtom]

můj oblíbený alias dud="du -h --max-depth=1", případně ncdu

[robertK]

Ja mam z netu tohle:

alias dud='du | grep -i -e '\''\.\(/[^/]\+\)\?$'\'' | sort -n | less'

[Michal Kubeček]

Můj oblíbený:

  du -x / | sort -n | tail -50

[Robo]

hehe

[LuděkS]

Nebo složitěji : du -s .[^.]* * | sort -n | tail -n 20

[samo]

ako je to u touch v pripade, ze chcem zmenit cas vzniku suboru? pretoze, ak to spravne chapem, ak kliknem na vlastnosti suboru, "creation time" ostane povodny.

(nemam momentalne dostupny linux, aby som si to overil...)

[Michal Kubeček]

Běžně používané linuxové filesystémy AFAIK čas vytvoření souboru neuchovávají.

[Amarok]

Jen dodam, ze ten cas vytvoreni by byl stejne nepodstatny (i kdyz se to na prvni pohled nezda), staci soubor napr. poslat e-mailem, nekdy staci zabalit do nejakeho archivu, ktery neuklada datumy apod. a puvodni datum je stejne pryc.

[Michal Kubeček]

Navíc je potřeba mít na paměti, že hloupější editory, které vytvářejí záložní kopie, si zjednodušují práci tím, že původní soubor přejmenují na jméno záložní kopie a nový uloží pod původním jménem. Pokud by takový editor neopravil creation timestamp (o čemž pochybuji, když autorovi nevadí ani to, že zboří hardlinky) tak by při každém "save" nenávratně zmizela.

[pht]

Program du slouží k odhadu zabraného místa danými soubory či adresáři

IMHO se zde nejedná o odhad, ale o přesnou hodnotu, kterou soubor zabírá na disku, což je potřeba brát doslova. Kvůli alokačním jednotkám a děravým souborům je skutečná velikost odlišná od velikosti na disku:

$ echo a > a
$ ls -l a
-rw-r--r-- 1 pht pht 2 2009-12-22 11:56 a
$ du a
4       a
$ dd if=/dev/zero of=a bs=1G seek=1000000 count=0
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.0858e-05 seconds, 0.0 kB/s
$ ls -lh a
-rw-r--r-- 1 pht pht 977T 2009-12-22 11:57 a
$ du a
4       a

Pokud chcete zjistit skutečnou velikost, např. pro účely stahování z webu, použijte přepínač --apparent-size, což je myslím pouze v GNU verzi.

[ne tamten divnej honza]

Ahoj, me se tento serial libi, takze pochvala pro autora a dik.

[AraxoN]

U príkazu file sa mi osvedčil ešte parameter --mime-type, ktorý robí presne to čo by ste si mysleli, že robí. Výstup je potom lepšie strojovo spracovateľný, napríklad v shell skripte...

[Michal Kubeček]

Ale to je relativně nová záležitost, ne? Protože jsem si celkem jistý, že ještě relativně nedávno (ne více než dva roky) jsem informaci o MIME typu v /etc/magic. Což byl IMHO také důvod, proč třeba Apache používal vlastní magic, kde byly místo slovních popisů MIME typy.

[AraxoN]

Neviem ako veľmi je tento parameter nový - používam ho cca rok a predtým som ho nepotreboval, takže ani nehľadal. Apache to rozoznáva podľa koncovky a myslím, že je to tak lepšie, než keby na všetko volal utilitu file.

[Michal Kubeček]

Apache umí rozeznávat podle koncovky (soubor mime.types a direktivaAddType) nebo na základě analýzy obsahu (modul mod_mime_magic). Ta druhá možnost se ale v praxi moc nevyužívá.

[Kvakor]

Ono by to nejspíš ani nestálo za tu námahu. Pokud si pamatuju, u souborů, které prohližeče nativně nepodporují a nezobrazují, často dávají přednost spíše příponě než MIME typu. Kdysi jsem to testoval a nakonec jsem po několika pomkusech vnutit typ souboru explicitně raději místo složitého detekování a odesílaní korekního MIME typu všem souborům nechával Content-Type nastavený na application/octet-stream, protože prohlížeče si to stejně zpracovávaly jak chtěly samy.

[Filip Jirsák]

Nikoli prohlížeče, ale jeden konkrétní prohlížeč, ten od Microsoftu. Aspoň jsem teda nezaznamenal, že by se Firefox pointernetoexplorerovatěl už i v tomhle.

[petr_p]

A nebo podle rozšířeného atributu user.mime_type – mod_mime_xattr :)