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

[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 :)