Zalety pliku cat'ing i orurowania do grep

Czy poza wygodą są jakieś dodatkowe korzyści związane z przechwytywaniem pliku i przesyłaniem go do grepa? Wygoda polega na tym, że kiedy pobieram polecenia z mojej historii, takie jak te poniżej, kursor znajduje się na końcu wiersza, więc łatwo jest zmodyfikować polecenie innym tekstem, aby grep na tym samym pliku.

Jakie więc mogą być inne zalety następującej konwencji:

cat /var/tmp/trace.2043925204.xt | grep -in profile
cat /var/tmp/trace.2043925204.xt | grep -n Profile-Main

zamiast:

grep -in profile /var/tmp/trace.2043925204.xt 
grep -n Profile-Main /var/tmp/trace.2043925204.xt 

Lepiej unikać kota; napisz to w ten sposób, jeśli edycja linii ma znaczenie:

$ < filename grep pattern

Powodem jest to, że przepychanie wszystkich danych przez cat kosztuje pamięć i zasoby procesora. Kolejną zaletą przekazania nazwy pliku jako argumentu zamiast przekierowania standardowego wejścia jest to, że pozwala on na polecenie mmap () pliku.

Nie wierzę, że nikt nie odwołuje „Useless Zastosowanie Cat” http://www.smallo.ruhr.de/award.html jeszcze

Jest jedna wątpliwa zaleta. Jeśli masz długi rurociąg, wygląda on trochę bardziej ortogonalnie z cat:

cat file | command1 | command 2 | command3

Gromadzi wszystkie polecenia razem.

Oczywiście, jak powiedzieli inni (i ja to robię)

< file command1 | command2 | command3

Wykonuje prawie to samo. To powiedziawszy, kot jest dość mały i nie spowoduje awarii komputera, jeśli go użyjesz, gdy tak naprawdę nie potrzebujesz.

Zwykle użycie catvs bezpośrednie uderzenie w plik nic nie zmienia, ale robi różnicę w przypadku niektórych poleceń, które mają znaczenie, jeśli argumentami jest wiele plików, takich jak grep. Przykładem:

cat file1 file2 | grep SOMETHING

będzie miał inną wydajność niż

grep SOMETHING file1 file2

Które będą mieć pasujące nazwy plików w danych wyjściowych. Są chwile, kiedy nie chcę nazw plików, a korzystanie z nich jest zaletą cat.

Nie ma przewagi. Kursor znajdujący się na końcu również nie ma większego znaczenia, jeśli zamiast tego utworzysz taką strukturę:< inputfile grep -args foo

W tej sytuacji po prostu wcale nie musisz używać kota. Jest to niepotrzebne i strata czasu, ponieważ narzędzia takie jak grep traktują nazwy plików jako argumenty.

[root@un1xf00 root]# time cat passwd | grep root
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin

real    0m0.021s
user    0m0.000s
sys     0m0.030s
[root@un1xf00 root]# time grep root passwd
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin

real    0m0.002s
user    0m0.000s
sys     0m0.000s
[root@un1xf00 root]#

Aktualizacja: Dzięki, @Andy Lester, za zwrócenie uwagi, że te czasy nie uwzględniają pamięci podręcznej dysku. Nauczyłem się czegoś nowego! Ale oszczędności ułamka sekundy i tak nie mają większego znaczenia. Po prostu myślę, że podłączenie kota do grepa nie jest logicznym sposobem robienia rzeczy. To tak, jakby poprosić kogoś innego o pomoc w rozwiązaniu problemu, gdy jesteś w stanie samodzielnie rozwiązać problem.

Łatwość edycji jest jedyną prawdziwą zaletą, a jeśli robisz to w wierszu poleceń, dodatkowy czas potrzebny na uruchomienie cati wykonanie potoku naprawdę nie zrobi różnicy.

Jednak nie ma powodu, aby robić to w skrypcie powłoki.

W ogóle nie ma korzyści. Zamiast martwić się o modyfikację poleceń, naucz się lepiej nawigować po linii poleceń powłoki za pomocą klawiszy i skrótów przyspieszających.

Nie, a w podanym przykładzie może być nawet nieco wolniejszy.

pipeJest tworzony między kotem a grep, która nie jest wymagana przy przejściu nazwę pliku bezpośrednio do grep. Jednak nie sądzę, aby pod żadnym pozorem zaobserwować ograniczenia przepustowości z tego powodu.

Inne zalety przesyłania danych wejściowych do grep obejmują wcześniejsze przetwarzanie, takie jak użycie narzędzi z bardziej zaawansowanymi możliwościami odczytu plików. (Zobacz tee, zcatmiędzy innymi).