Portál AbcLinuxu, 21. května 2025 19:00
Mezi kolegy jsem byl jiz nekolikrat svedkem svedomiteho pouzivani prikazu more
na miste kde by melo byt cat
, napr:
more /etc/passwd | grep root
Nikdy jsem nekoukal do vnitrnosti (uprimne, ani do man
u) more
, ale moje dosavadni poznani (unix) sveta mi rika, ze:
cat
more
byl napsan pro to, aby "pozastavil" vypis na obrazovku vzdy po $pocet_radku radcich a cekal na stisk klavesy. Predpokladam, ze more
je naprogramovan natolik inteligentne, ze si (stejne jako napr. ls
kontroluje vystup, do ktereho pise, a pokud se nejedna o terminal ( man 3 isatty
), t.j. pise do roury nebo do souboru, tak se nenamaha s "pozastavovanim" vystupu, protoze to nema cenu (proc pozastavovat kdyz vystup jde treba do souboru, ze?), a tudiz se vlastne jedna o cat
more
- less
(kde je k dispozici, coz dnes je skoro kazdy "UN*X flawor", skoro kazda distribuce)
Bohuzel, nic z vyse uvedeneho mi nedava zadne "zbrane" do rukou v pripade ze bych chtel kolegum vysvetlit proc to co delaji je spatne a proc by meli pouzivat cat
, kdyz "it works this way".
Stale me ovsem trapi 2 otazky:
more
na miste kde by melo byt cat
zpusobit problemy? Existuji implementace more
ktere nekontroluji vystupni zarizeni a VZDY pozastavuji vystup?more
? Je v DOSu (win dos boxu) ekvivalent cat
?
Tiskni
Sdílej:
Mas pravdu, asi jsem zvolil spatnej priklad. Co tohle:
more /etc/passwd|tr -d ":" |grep root
I kdyz otazka je asi porad stejna: jestlize nasledujici prikazy delaji totez, proc bychom meli preferovat 3.?
more /etc/passwd|grep root
cat /etc/passwd|grep root
grep root /etc/passwd
Asi jde jenom o akademickou otazku a meli bychom nechavat uzivatelum svobodu (ale at nam proboha nepisou takova zverstva do skriptu, i kdyz vlastne neskodi )
jestlize nasledujici prikazy delaji totez, proc bychom meli preferovat 3.?Abychom pouzivali program k tomu, k cemu byl urcen. K cemu byl urcen je dano v manualove strance:
cat - concatenate files and print on the standard outputTady nic nespojuju a proto ta 3
Tato argumentace se mi libi, a beru ji jako odpoved na sve otazky, diky
Doted jsem pouzival cat
v pripade "potrebuju neco dostat na obrazovku", pripadne potrebuju dostat obsah souboru na std. vstup neceho jinyho. Az ted mi doslo, ze pro druhy pripad je lepsi pouzit presmerovani vstupu (grep root < /etc/passwd
), ale co v pripade pokud proste potrebuju dostat na terminal obsah souboru? Jsem opravnen pouzit cat
(kdyz tim nesplnim prvni podminku z manu), nebo musim pouzit nastroj?
Pri obede jsem tak premyslel co nas nuti "pedantsky" trvat na malickostech, jako je toto striktni pouzivani veci na to naco byly urceny. Bud k tomu clovek dochazi vekem (no nevim), zkusenostmi (tolikrat se mi stalo ze kvuli spatne pouzitymu prikazu, ktery "proste fungoval", a v jine situaci nefungoval)? Jeste je tu jina odpoved - na to aby clovek byl pouzitelne dobry vyvojar/admin, musi byt puntickar (bohuzel ted nemuzu najit ten prispevek ze ktereho tato myslenka pochazi)...
Concatenate FILE(s), or standard input, to standard output.Zrovna tak SYNOPSIS zni
cat [OPTION] [FILE]...A co ted s tim?
Dik, to je ono.
Clovek by rekl ze je to drobnost, pri dnesnich vykonech pocitacu, ale stejne, v hodne zatizenym stroji, nebo v pripade ze dany skript pobezi x-tisic-krat to bude sakra znat. Jeste jednou diky za nakopnuti.
cat
jako interní příkaz a měli jsme od této pochybné argumentace pokoj…
cat
(nič nerobiaci filter), ak nie, zamyslím sa nad otázkou ešte raz.
cat
je ok, znamená "žiaden filter", imho je lepšie používať $cat < $file
, zmeniť premennú na iný príkaz je jednoduchšie ako hľadať "kde kua to ešte nie je". cat
je fakt divnej příkaz. Většinou to vypadá, že ho lidi používaj jen aby ukázali, že ho znají $PAGER
(a tie lepšie jej aj nastavujú default hodnotu, povedzme práve na cat
alebo more
)
type
, ale nejsem si úplně jistý, zda po provedení type X > Y
, kde X je obecný soubor, budou mít oba soubory vždy stejný obsah (help type
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.