Unixové nástroje – 1 (úvod, cat, head, tail) (diskuse)

[xxxs]

ak sa tempo prilis nezrychli, tak sa aj nieco zaujimave naucim. je to predychatelnejsie ako man stranky. dik.

[filo]

Taky děkuju, příjemně se to čte.

[Pavel Půlpán]

Jj, pokud Dejv vydrží, bude z toho povedenej seriál, kerej budeme kdykoliv moct cli-lamám a cli-ignorantům vomlátit o držky.

[Robert Krátký]

pokud Dejv vydrží, bude z toho povedenej seriál

Sestavujeme s Davidem seznam všech možných příkazů, o kterých by bylo fajn napsat (a pokusili jsme se je seskupit podle významu do článků). Vzhledem k tomu, jak je už teď ten seznam dlouhý, si myslím, že by se David nezlobil, kdyby se některých dílů chopili i jiní autoři. Pokud máte někdo zájem, ozvěte se na redakce AT abclinuxu.cz.

[Pavel Půlpán]

Předpokládám, že se seznam zveřejní, dejme tomu v blogu?! Možná bych se taky při troše volného času něčeho pokusil ujmout.

[David Watzke]

Určitě bych se nezlobil a ten seznam klidně pak zveřejním v blogu a můžem ho upravovat podle dobrých nápadů v komentářích.

[Prcek]

cat soubor.txt | grep "slovo"

Tak tohle používám pořád a teď se dozvím, že je to "špatně" .

Mimochodem, ve větě "...ale vypisuje je po řádkách..." by mělo být spíš "řádcích", jelikož všude jinde používáš "ten řádek" a ne "ta řádka" . A možná by to chtělo ukázat i nějaký složitější kouzla s těmi programy - třeba to zapojení do roury, když už se o ní zmiňuješ. Ale jinak chválím, základy je třeba umět a ten seriál by mohl být přínosný začátečníkům i pokročilým (jak se ukázalo u mě a catu ).

[deda.jabko]

Tak tohle používám pořád a teď se dozvím, že je to "špatně" .

neni to spatne... jenom si to mysli nekolik anticat-fasistu... :-]]

ja ten zapis ,,cat foo | bar'' mam radsi, protoze kdyz se ladi nejaka slozitejsi roura je mozne velice jednoduse vymenit vstup... napr. kdyz chcu udelat nejaky dump z logu tak si rouru odladim pro vstup head -n 100 a kdyz jsem spokojeny s vystupem prohodim jenom head za cat nebo treba zcat a je vystarano...

navic, ne kazdy program ma jako argument vstupni soubor jako grep... takze pouziti cat je evidentne obecnejsi reseni

[David Watzke]

Když použiješ to přesměrování, tak to není vstupní argument, ale shell mu to dá na stdin. Podobně jako kdybys použil ten cat, ale efektivněji.

[posejdon]

pouzivam cat neco.txt|grep vyraz, protoze jsem liny se podivat do napovedy, jestli nazev souboru je prvni nebo posledni parametr a jestli se to vola s prepinacem nebo bez. Samozrejme to takto pouzivam, kdyz neco pisu primo do radky, kdybych mel psat nejakej skriptik, tak se mozna hecnu a na tu syntaxi se podivam.

[Andrej]

Toto je odpověď à la absurdní drama. David se snažil naznačit, že není potřeba si pamatovat způsob zadávání vstupního souboru.

Pokud si to čirou náhodou pamatuju, můžu napsat

grep franta /etc/passwd

Tady příslušný soubor otevře přímo grep. Pokud si pořadí parametrů pamatovat nechci, nikdo mě k tomu nenutí. Může to v konečném důsledku znamenat dokonce i méně práce pro můj počítač, pokud jde o počet současně existujících file descriptorů. Místo parametru použiji vymoženost zabudovanou přímo v shellu:

grep franta < /etc/passwd

Tady soubor otevře shell a grep bude prostě číst svůj standardní vstup. Žádný proces navíc, žádný file descriptor navíc.

[Radek Hladik]

Tohle je pravda a i tak jsem to z článku pochopil. Mně na tom ale vadí jedna věc. Když zapíšu

grep franta < /etc/passwd

tak to je v obráceném pořadí (kolony se čtou zleva doprava), takže třeba

grep franta </etc/passwd | sort | uniq

a když naopak zapíšu

</etc/passwd grep franta | sort | uinq

tak se mi nelíbí, že ta šipka směřuje na druhou stranu. A navíc, pokud budu vypisovat nějakej delší soubor, tak ta | to pěkně vizuálně oddělí.

Ale jinak se myslím všichni shodneme, že se tu bavíme o marginální okrajovosti a jde spíše jen o takové relaxační potlachání

[xkucf03]

kolony?

[Radek Hladik]

Ano, já se o tom vždycky učil jako o koloně.

Roura, trubka, kolona, anonymní roura, konvenční roura (anglicky pipeline) je v unixových systémech původním nástrojem pro spojování procesů do řetězce pomocí vzájemného propojení standardních proudů tak, že je vždy výstup (stdout) procesu nasměrován přímo do vstupu (stdin) následujícího procesu.   Viz http://cs.wikipedia.org/wiki/Roura_%28Unix%29

Takže | je krásně česky pajpa a více zřetězených příkazů pomocí pajpy je kolona... Nebo třeba z http://www.kiv.zcu.cz/~txkoutny/common/ups/skoleni/skoleni-unix-3.html :

|       roura (pipe) - řazení příkazů do kolony

[xkucf03]

Vím, o co jde ale „kolona“ zní naprosto příšerně

[Ladicek]

Kolona vypadá, zní a je úplně v pořádku

[snehuliak]

Mozno kolona je uplne poriadku ale ani mne sa velmi nepaci. Aj v Slovencine mame slova ktore su spisovne a "uplne vporaidku" ale nikto ich nepouziva napriklad:

posilnovna (nespravne posilovna), hovnik (nespravne pohovka), lezun (nespravne batola) a hranolceky (nespravne hranolky)...

Inak spisovny jazyk je vynalez akademikov, skutocny jazyk je taky ktory sa pouziva a ktorym sa ludia dorozumeju. Inak spisovna anglictina v podstate neexistuje takze neverte ucitelom anglictiny ak vam povedia ze sa nieco "takto" nehovori alebo ze je nieco nespravne - urcite sa da najst priklad kedy sa to tak pouziva ;)

Inak kolona mi evokuje anglicke colon [kolon] co je dvojbodka ;)

[Ladicek]

Tak já jsem výjimečně o spisovnosti vůbec nemluvil Kolona je … no prostě kolona, řada aut od nevidím do nevidím na cestě mezi Prahou a Brnem , no nebo řada rour v shellu. Často taky od nevidím do nevidím.

[Jiří Svoboda]

Nebo destilační kolona. A zrovna ta mi přijde shellu nejpodobnější. Každý další příkaz něco získá z výsledku předchozího.

[Ladicek]

Vím, že chemici mají taky nějakou kolonu, ale nic o tom nevím. Ale destilační kolona zní sexy

[Jakub Lucký]

A taky mají frakční kolonu, pokud mě má rok a půl chemií netknutá paměť nešálí... A snad je to dokonce totéž...

[Michal Kubeček]

V principu je to totéž, ale frakční destilace bývá důkladnější, takže umožňuje lépe oddělit složky s blízkým bodem varu.

[Michal Kubeček]

Seriál M*A*S*H jste neviděl? Tam se o ní mluví každou chvíli…

[thefox]

Pred šírením týchto urban legends o "neuveriteľných spisovných slovách" by bolo vhodné konzultovať slovník (napr. online na http://slovnik.juls.savba.sk/). Hovník ani lezúň neexistujú (dokonca o tom lezúňovi som teraz čítal prvýkrát), pohovka aj batoľa sú normálne spisovné slová.

Mne colon pripomína niečo úplne iné, kto si užil kolonoskopiu, tomu to asi zostane...

[xxxs]

to crevo je ok, tiez je to kolona.

[Michal Kubeček]

Ty výrazy na mne působí, jako by je vymýšleli podobní bojovníci za nedorozumění mezi národy jako ti, kteří se od rozdělení Jugoslávie usilovně snaží ze srbochorvatštiny vyrobit dva různé jazyky.

[Ash]

posilnovna (nespravne posilovna), hovnik (nespravne pohovka), lezun (nespravne batola) a hranolceky (nespravne hranolky)...

A nechtěl byste rovnou mluvit česky? (Teda až na batole).

[Jakub Lucký]

Nechtěli... to je na Slovensku za pokutu ;)

[Jendа]

Používá tu někdo pojmenování pípa?

[Kvakor]

Mám pocit, že jsem kdysi někde v nějakém starém (10let+) návodu viděl, bohužel googlení mi nalezlo pouze stránky s pivní tématikou

Mimo toho jsem slyšel i termíny fífa a pajpa (nejspíš počeštěné pipe) a pro pipeline dokonce termín rourárna (nejspíš inspirace zpotvořeným slovníkem strážníka Crabtreeho z britského seriálu "Haló, haló" ).

[Jarda]

Ja pouzivam slova pipa nebo roura, nemam rad pocestena anglicka slova (napr. pajpa, pisicko, apod.)

[Michal Kubeček]

Pro mne je problém v něčem jiném. Potřebuju-li vložit filtr na začátek, tak při použití cat mám

  cat file | filter1 -args1 | filter2 -args2 ...
  cat file | filter0 -args0 | filter1 -args | filter2 -args2 ...

tj. jen vložím filtr tam, kam je potřeba. Oproti tomu bez cat to vypadá takto:

  filter1 -args1 <file | filter2 -args2 ...
  filter0 -args0 <file | filter1 -args1 | filter2 -args2 ...

tj. musím vytáhnout to přesměrování a přesunout ho před filtr, který byl původně první. A tohle nepohodlí mi za jeden ušetřený proces nestojí, zvlášť jde-li o interaktivní práci, kdy stejně počítač drtivou většinu času čeká na mne.

Ano, vím, že bash umožňuje napsat přesměrování před příkaz. Ale jednak to považuji za nechutnou prasárnu, jednak si moc nejsem jistý přenositelností této konstrukce.

[Jendа]

<file filter1 -args1 | filter2 -args2
<file filter0 -args0 | filter1 -args1 | filter2 -args2

Zdá se mi to takové nezvyklé, možná i hůř čitelné než s catem (možná je to proto, že mám v PS1 zobáček).

[Michal Kubeček]

Viz poslední odstavec příspěvku, na který reagujete (tvz. preventivní odpověď :-) ).

[Jendа]

Aha

(Šíří se to! Kromě Jirsáka už mi má potřebu vykat i Kubeček! Pomóc!)

[xxxs]

kamo, asi starnes.

[Michal Kubeček]

To není nic osobního, já tu vykám všem. :-) Tedy kromě těch, se kterými si tykám v reálu.

[Robo]

njn, ak niekto vytahuje pri debate o scriptovani v shelly argument, ze pouzitie cat-u je neefektivne je to smiesne; cele scriptovanie v shelly je neefektivne a na komplexnejsie ulohy sa nehodi

[Robo]

+1, pametat si argumenty pre vstupny subor roznych programov je nad moje sily

[xkucf03]

Asi tak.

cat soubor.txt | grep slovo | … mi přijde přehlednější – člověk vidí ty jednotlivé | a hned si to rozdělí na posloupnost příkazů.

Zápisem grep slovo < soubor.txt | … se sice ušetří vytváření procesu catu, ale vetšinou je to úplně jedno.

Zápis grep slovo soubor.txt mi přijde trochu proti té unixové filosofii, grep totiž musí umět pracovat se soubory, i když by stačilo, aby pracoval jen se standardním vstupem/výstupem a vše ostatní se řešilo rourami/přesměrováním.

[kuly]

musí umět pracovat se soubory, i když by stačilo, aby pracoval jen se standardním vstupem/výstupem

Vzhledem k tomu, že všechno je soubor, tak se soubory pracovat umí. Použití jiného souboru než stdin je záležitost na dva řádky.

[xkucf03]

Plus ještě další if-větvení + zpracování parametrů příkazové řádky + manuálové stránky + ošetření dalších chyb… je toho víc.

Na druhou stranu grep toho dělá víc než obyčejné grepování (např. rekurzivní procházení adresáře, kdy grepuje všechny soubory a na výstup vypisuje nejen řádky, ale i název souboru, ze kterého pocházejí), takže by se soubory pracoval tak jako tak.

BTW: když jsem si teď procházel zdrojáky grepu, tak jsem si všimul, že se tam definuje:

/* Long options equivalences. */
static struct option const long_options[] =
{
  {"after-context", required_argument, NULL, 'A'},
  {"basic-regexp", no_argument, NULL, 'G'},
  {"before-context", required_argument, NULL, 'B'},
  {"binary-files", required_argument, NULL, BINARY_FILES_OPTION},
  {"byte-offset", no_argument, NULL, 'b'},
  {"context", required_argument, NULL, 'C'},
  {"color", optional_argument, NULL, COLOR_OPTION},
…

tedy parametry příkazové řádky a totéž potom v nápovědě:

printf (_("Usage: %s [OPTION]... PATTERN [FILE] ...\n"), program_name);
      printf (_("\
Search for PATTERN in each FILE or standard input.\n\
Example: %s -i 'hello world' menu.h main.c\n\
\n\
Regexp selection and interpretation:\n"), program_name);
      printf (_("\
  -E, --extended-regexp     PATTERN is an extended regular expression\n\
  -F, --fixed-strings       PATTERN is a set of newline-separated strings\n\
  -G, --basic-regexp        PATTERN is a basic regular expression\n\
  -P, --perl-regexp         PATTERN is a Perl regular expression\n"));
      printf (_("\
  -e, --regexp=PATTERN      use PATTERN as a regular expression\n\
  -f, --file=FILE           obtain PATTERN from FILE\n\
  -i, --ignore-case         ignore case distinctions\n\
…

A do třetice to musí být ještě v manuálové stránce.

Není na to nějaká knihovna nebo postup, abych definoval na jednom místě krátký parametr, dlouhý parametr a popis a nápověda a manuálová stránka se z toho jen vygenerovala?

[Jakub Lucký]

s catem to trvá déle... Zkuste to změřit přes time...

[Ash]

Pro někoho, kdo si myslí, že každý program umí číst z roury, a proto cat rulez, je cat jistě obecnější řešení :)

[Radek Hladik]

Taky mi to připadá takový přehlednější a čistší. Jeden program dělá grepování a druhý čtení ze souboru. A upřímně řečeno, kdy naposledy jste někdo psal takovou kolonu, že by ten jeden proces navíc hrál tak zásadní roli? Ale líbí se mi to, že si každý může vybrat, ať je lenoch jako já, nebo anticat fašista

Ale nejvíc mě to štvalo, když jistý nejmenovaný profesor u zkoušky považoval přebytečné cat za chybu zhoršující známku o stupeň. Ale alespoň to oznámil předem...

[David Watzke]

Ty se označuješ za lenocha a píšeš zbytečnej příkaz navíc, to je pozoruhodný

[Radek Hladik]

Jo, možná to zní divně, ale je to tak Napsat jeden příkaz navíc je míň práce, než měnit něco, co používám už dlouho

[rich]

tak to se ani nedivim, ze to v nasi politice vypada tak jak to vypada, kdyz lide uvazuji podobnym zpusobem. ale to uz k smichu moc neni

[xyz]

Stará známá pravda říká, že línej se nejvíc nadře.

[error414]

kravina, lenost je motor lidstva

[D.A.Tiger]

Jj. z lenosti vzniklo nejvíc vynálezů Potom ještě pro vojenské účely...

[Drom]

Jo jo, skoda ze nejsou lidi dost liny, aby prestali valcit. Pak se bude konecne moct rozvinout Lazy Power :D

[Leoš Literák]

nedavno jsem na mandrive objevil zkratku tailf, usetrim dva uhozy

[darth.vader]

ten 'tail -f soubor' je dobra vec. Jeste s oblibou vyuzivam less. Tam lze pomoci velkeho 'F' docilit stejneho efektu akorat s tim, ze tento mod muzete kdykoliv prerusit a nasledne se pomoci vyhledavacich funkci vratit k zajimavemu mistu.

[mimi.vx]

misto tail -f soubor existuje prikaz 'tailf'

[Michal Kubeček]

To rozhodně není standardní příkaz. Možná to jen některá distribuce defaultně nastavuje jako alias. To bych stejně tak mohl tvrdit, že existují "příkazy" ls-l nebo cd..

[Prcek]

No já nevím, ale u mě na Gentoo jsem zkoušel which tailf a vrátilo mi to /usr/bin/tailf, což je normální binárka, alias by to asi takhle nenašlo.

[Marián Kyral]

Z man tailf:

 

It is similar to tail -f but does not access the file when it is not growing.

 

[Mazarik]

K tail -f existuje este tailf, ktory na rozdiel od prveho nemeni casy pristupu k sledovanemu suboru.

[Radovan Garabík]

a existuje aj GNU extension tail -F, ktorá je pre sledovanie /var/log/* súborov podstatne výhodnejšia ako tail -f .... 

[Michal Vyskočil]

U příkazu tail bych vypíchnul spíše -F. Ten zvládá i přesouvání souborů, což je u logů poměrně typické.

[maertien(not logged in)]

Nu, pekny navod. Ale nebyla zde nekde nejaka obdobna ucebnice?

[maertien(not logged in)]

Dobra. Omlouvam se. Ucebnice je vyrazne strucnejsi.

[Robo]

velmi dobra ucebnica je Advanced Bash Scripting Guide

[YYY]

Jasny, ale ja mel na mysli ucebnici zde na abicku.

[otasomil]

Velmi casto pouzivam:

cat /dev/sda1 > zaloha_windows_datum.bin

a nazpet

cat zaloha_windows_datum.bin > /dev/sda1

HDD oddil je vlastne "jenom" takovy "kus textu" .... zrovna u me ma 15 GB.

[Michal Kubeček]

Na to stačí i cp. :-)

[xkucf03]

dd s vhodně nastaveným bs=x by měl být efektivnější, ne?

[xkucf03]

Tohle testuje jenom čtení, ale stejně:

$ dd if=záloha-2009-04-10.7z of=/dev/null bs=1M
9+1 vstoupivších záznamů
9+1 vystoupivších záznamů
10 333 503 bajtů (10 MB) zkopírováno, 0,00965979 s, 1,1 GB/s 

$ cat záloha-2009-04-10.7z | dd of=/dev/null bs=1M
9+1 vstoupivších záznamů
9+1 vystoupivších záznamů
10 333 503 bajtů (10 MB) zkopírováno, 0,0206071 s, 501 MB/s

$ dd if=záloha-2009-04-10.7z bs=1M > /dev/null
9+1 vstoupivších záznamů
9+1 vystoupivších záznamů
10 333 503 bajtů (10 MB) zkopírováno, 0,00981492 s, 1,1 GB/s

$ <záloha-2009-04-10.7z dd bs=1M > /dev/null
9+1 vstoupivších záznamů
9+1 vystoupivších záznamů
10 333 503 bajtů (10 MB) zkopírováno, 0,00989328 s, 1,0 GB/s

[otasomil]

>>> 1,1 GB/s ???

Ten soubor (if) mate predpokladam v ramdisku. Pac ta rychlost je opravdu monstrozni.

Jakou rychlosti poslete do /dev/null soubor vetsi velikosti (radove nekolik GB) a nebo rovnou filesystem (if=/dev/sd*) ?

[xkucf03]

Na ramdisku není, je to na ex4 na LVM na šifrovaném disku.

Ale nebylo to první čtení toho souboru, takže se data brala z diskové cache. První čtení bylo jen kolem 40 MB/s

$ dd if=soubor.bin bs=1M of=/dev/null
11+1 vstoupivších záznamů                                                     
11+1 vystoupivších záznamů                                                    
12 340 695 bajtů (12 MB) zkopírováno, 0,310885 s, 39,7 MB/s                   

$ dd if=soubor.bin bs=1M of=/dev/null
11+1 vstoupivších záznamů
11+1 vystoupivších záznamů
12 340 695 bajtů (12 MB) zkopírováno, 0,0137188 s, 900 MB/s

[H o n z a]

Dobry,

az na to, ze "#cat cosi > /dev/null" NENI totez jako "#cat cosi | dd of=/dev/null".

(Tipnu si, ze druhy prikaz pristupuje do pameti dvakrat. Coz se zvlaste u cteni pouze z RAM asi dost projevi)

Zkusil jsem #time $prikaz a zde je zebricek:

0.311s -- cp x.vob /dev/null

0.315s -- cat x.vob > /dev/null

0.321s -- dd if=x.vob of=/dev/null bs=256k

0.371s -- dd if=x.vob of=/dev/null bs=1M

0.719s -- cat x.vob | dd of=/dev/null bs=256k

0.740s -- cat x.vob | dd of=/dev/null bs=1M

(cas - REAL; x.vob - 1024MB; RAM DDRII 2GB 666Mhz DualChanel)

Muj zaver: V jednoduchych pripadech je temer jedno, zda cp, cat nebo dd. Hlavne se vyvarovat se nadbytecnych rour.

[otasomil]

Da se to tak nejak srovnat. Pokud bs neni prilis nizke (radove stovky bajtu a min - rychlost jde dolu) tak bych to povazoval za rovnocenne. Jinak samozrejme dd je nastroj primo pro tyto ucely.

[Kvakor]

Nebo pv - pokud něco může trvat delší dobu, je dobré vidět progressbar.

[Jendа]

Když pošleš ddčku USR1, tak ti taky ukáže, kolik už toho zkopírovalo.

[xkucf03]

pěkne, to jsem neznal

[me]

anebo si nainstlalovat dd_rescue, pouzivat jej misto dd, na velke objemy dat se hodi lepe.

[snehuliak]

cat soubor.txt | grep "slovo"

Pouzivam vtedy ked ich robim viac, pricom manualne potrebujem zmenit "slovo". Vtedy v bash-i dam len sipku hore a mozem hned zmazat stare slovo a nahradit novym.

Ak ma subor.txt iba ~100 riadkov, je rozdiel vo "vykone" uplne zanedbatelny, ale rozdiel v editacii riadku nie. Cize vlastne "pomalsia" varianta je rychlejsia.

Mohol by som sice pouzit makro alebo mini script ale neoplati sa ;)

[David Watzke]

Nebo můžeš použít přesměrování na začátku

< soubor.txt grep "slovo"

[snehuliak]

priznam sa ze premerovanie na zaciatku som nepoznal a ani sa mi nezda velmi logicke.

kde vsade to funguje? je to iba bash-ovina?

[David Watzke]

Není to jen bashovina, třeba zsh umí i vícenásobné přesměrování, což je teprve nářez. Třeba:

echo ahoj > 1.txt > 2.txt > 3.txt

(a totéž umí i obráceně s <)

[snehuliak]

zacinam sa zamotavat...

skusil som si v bashi tvoj priklad - len zo srandy:

$ echo 1 > 1 > 2 > 3

A vysledok:

$ cat 1
$ cat 2
$ cat 3
1

Otazka je: preco?

Podrobnejsia otazka je: preco su 1 a 2 prazdne a vysledok je az v 3 ?

[Michal Kubeček]

Zjednodušená odpověď: protože přesměrování se vyhodnocují postupně a každé nové "přebije" předchozí. Podrobnější odpověď: každé přesměrování spočívá v něčem jako

  int fd = open(fname, ...);
  dup2(fd, STDOUT_FILENO);

Takže ať jich napíšete, kolik chcete, nakonec pod deskriptorem 1 máte vždy ten poslední soubor. Z podobných důvodů 'cmd >file 2>&1' přesměruje starndardní i chybový výstup do souboru, ale 'cmd 2>&1 >file' přesměruje jen standardní výstup.

[snehuliak]

Velmi pekne dakujem za odpoved. Konecne tomu rozumiem. Doteraz som celkom nechapal preco "zalezi na poradi" - iba som tento fakt akceptoval. Priklad s dup2 to uplne vyjasnil (aj ked som pozrel zopar manualovych stranok pre dup2 aby som si vyjasnil ako to funguje).

Pre tych co tiez nechapu prikladam odkazy na manualove stranky:

http://www.opengroup.org/onlinepubs/009695399/functions/dup.html
http://www.mkssoftware.com/docs/man3/dup2.3.asp
http://linux.die.net/man/2/dup2

DIKI!!!

 

[Michal Kubeček]

Na druhou stranu, zsh je ještě bashovitější než bash, v kladném i záporném smyslu. :-)

[snehuliak]

este som skusil

< soubor.txt

v bashi aj v zsh: Bash nevypise nic, zsh vypise obsah suboru - ako cat ;) 

[Ash]

Ale content=$(<soubor.txt); echo $content už to vypíše a docela často se to i hodí.

[snehuliak]

A este jedna vec, najprv by bolo mozne dobre vysvetlil co tie rury (kolony) vlastne su a troch o standardnom vstupe a vystupe. Navyse tieto veci sa zavisle aj na pouzitom shelli takze by bolo asi dobre popisat aj shell - ale potom sa obavam ze by sa auto tak skoro ku cat nedostal...

Inak "Nie je všetko sh, čo sa blyští" - konkretne mam na mysli Ubuntu sh (=dash) a Fedora sh (=bash)... ;)

[Dalibor Smolík]

 Díky, velmi zajímavý článek

[Amarok]

Kdyz team GNU prepisoval vsechny coreutils pro linux, proc uz aspon vse nesjednotili v pouzivani? Prece -v znamena vetsinou "verbose", ale koukam, ze u cat to ma uplne jiny vyznam a na takove odchylky narazim casteji... :(

[Michal Kubeček]

Pádným argumentem proti takovému sjednocování bývá jednak zpětná kompatibilita (představa, že stejný přepínač má v různých verzích různé funkce, se mi ani trochu nelíbí), jednak POSIX compliance (rozšíření jsou jedna věc, ale pokud by POSIXem definovaný přepínač u GNU dělal něco jiného, byl by to problém).