Czy powinienem dbać o niepotrzebne koty?

Wiele narzędzi wiersza polecenia może pobierać dane wejściowe z potoku lub jako argument nazwy pliku. W przypadku skryptów o długiej powłoce rozpoczęcie łańcucha od znaku catsprawia, że ​​jest on bardziej czytelny, zwłaszcza jeśli pierwsze polecenie wymaga wieloliniowych argumentów.

Porównać

sed s/bla/blaha/ data \
| grep blah \
| grep -n babla

i

cat data \
| sed s/bla/blaha/ \
| grep blah \
| grep -n babla

Czy ta ostatnia metoda jest mniej wydajna? Jeśli tak, czy różnica jest wystarczająca, aby się martwić, czy skrypt zostanie uruchomiony, powiedzmy, raz na sekundę? Różnica w czytelności nie jest ogromna.

„Ostateczna” odpowiedź jest oczywiście dostarczana przez The Useless Use of catAward .

Celem cat jest łączenie plików (lub „catenate”). Jeśli jest to tylko jeden plik, połączenie go z niczym nie jest stratą czasu i kosztuje proces.

Utworzenie instancji cat tylko po to, by Twój kod odczytywał inaczej, zapewnia jeszcze jeden proces i jeszcze jeden zestaw strumieni wejściowych / wyjściowych, które nie są potrzebne. Zazwyczaj prawdziwym problemem w skryptach będą nieefektywne pętle i przetwarzanie. W większości nowoczesnych systemów jeden dodatkowy catnie zabije twojej wydajności, ale prawie zawsze istnieje inny sposób na napisanie kodu.

Jak zauważyłeś, większość programów jest w stanie zaakceptować argument dla pliku wejściowego. Jednak zawsze istnieje wbudowana powłoka, <której można użyć wszędzie tam, gdzie oczekuje się strumienia STDIN, co pozwoli ci zaoszczędzić jeden proces, wykonując pracę w już uruchomionym procesie powłoki.

Możesz nawet wykazać się kreatywnością GDZIE to piszesz. Zwykle byłby umieszczony na końcu polecenia przed określeniem przekierowań wyjściowych lub potoków takich jak to:

sed s/blah/blaha/ < data | pipe

Ale nie musi tak być. Może nawet być na pierwszym miejscu. Na przykład twój przykładowy kod może być napisany w następujący sposób:

< data \
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla

Jeśli zależy Ci na czytelności skryptu, a kod jest na tyle bałaganiarski, że dodanie wiersza dla catma ułatwić śledzenie, istnieją inne sposoby wyczyszczenia kodu. Jednym z nich, z którego często korzystam, co ułatwia późniejsze rozpoznawanie skryptów, jest dzielenie potoków na logiczne zestawy i zapisywanie ich w funkcjach. Kod skryptu staje się wtedy bardzo naturalny, a każda część potoku jest łatwiejsza do debugowania.

function fix_blahs () {
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla
}

fix_blahs < data

Następnie możesz kontynuować fix_blahs < data | fix_frogs | reorder | format_for_sql. Ścieżka, która tak czyta, jest naprawdę łatwa do naśladowania, a poszczególne komponenty można łatwo debugować w odpowiednich funkcjach.

Oto podsumowanie niektórych wad:

cat $file | cmd

koniec

< $file cmd

• Po pierwsze, uwaga: brakuje (celowo dla celów dyskusji) podwójnych cudzysłowów $filepowyżej. W przypadku catjest to zawsze problem, z wyjątkiem zsh; w przypadku przekierowania jest to tylko problem dla bashlub, ksh88a dla niektórych innych powłok tylko w trybie interaktywnym (nie w skryptach).
• Najczęściej wymienianą wadą jest spawnowanie dodatkowego procesu. Zauważ, że jeśli cmdjest wbudowany, to nawet 2 procesy w niektórych powłokach, takich jak bash.
• Nadal na froncie wydajności, z wyjątkiem powłok, w których catjest wbudowany, że wykonywane jest także dodatkowe polecenie (i oczywiście ładowane i inicjowane (oraz biblioteki, z którymi jest powiązany)).
• Jeszcze na froncie wydajności, w przypadku dużych plików, oznacza to, że system będzie musiał zaplanować przemian cati cmdprocesów oraz stale napełnić i opróżnić bufor rury. Nawet jeśli cmdrobi 1GBduży read()układ połączeń na raz, kontrola będzie musiał przejść tam iz powrotem pomiędzy cata cmdponieważ rura nie może posiadać więcej niż kilka kilobajtów danych na raz.
• Niektórzy cmd(jak wc -c) mogą dokonać optymalizacji, gdy ich standardowe wejście jest zwykłym plikiem, z którym nie mogą cat | cmdsobie poradzić, ponieważ ich standardowe wejście jest wtedy tylko potokiem. Za pomocą cati potoku oznacza to również, że nie mogą one seek()znajdować się w pliku. W przypadku poleceń takich jak taclub tail, ma to ogromną różnicę w wydajności, ponieważ oznacza to, że wraz z catnimi muszą przechowywać całe dane wejściowe w pamięci.
• cat $file, A nawet jego bardziej poprawna wersja cat -- "$file"nie będzie działać prawidłowo w przypadku niektórych określonych nazw plików, takich jak -(lub --helpczy cokolwiek zaczynając -przypadku zapomnienia --). Jeśli ktoś nalega na użycie cat, prawdopodobnie powinien cat < "$file" | cmdzamiast tego użyć niezawodności.
• Jeśli $filenie można go otworzyć do odczytu (odmowa dostępu, nie istnieje ...), < "$file" cmdzgłosi spójny komunikat o błędzie (przez powłokę) i nie uruchomi się cmd, podczas gdy cat $file | cmdnadal będzie działać, cmdale ze standardowym stdin wygląda jak pusty plik. Oznacza to również, że w takie rzeczy < file cmd > file2, file2nie jest niszczona, jeśli filenie można otworzyć.

Umieszczenie <filena końcu potoku jest mniej czytelne niż cat filena początku. Naturalny angielski czyta od lewej do prawej.

Umieszczenie <fileA początek rurociągu jest mniej czytelny niż kot, powiedziałbym. Słowo jest bardziej czytelne niż symbol, zwłaszcza symbol, który wydaje się wskazywać w niewłaściwy sposób.

Użycie catzachowuje command | command | commandformat.

Jedną z rzeczy, na które inne odpowiedzi tutaj nie wydają się bezpośrednio dotyczyć, jest to, że cattakie użycie nie jest „bezużyteczne” w tym sensie, że „pojawia się zewnętrzny proces kota, który nie działa”; jest bezużyteczny w tym sensie, że „spawnowany jest proces kota, który wykonuje tylko niepotrzebną pracę”.

W przypadku tych dwóch:

sed 's/foo/bar/' somefile
<somefile sed 's/foo/bar/'

powłoka uruchamia proces sed, który odczytuje odpowiednio z pliku tymczasowego lub standardowego, a następnie wykonuje pewne przetwarzanie - odczytuje, dopóki nie trafi do nowej linii, zastępuje pierwsze „foo” (jeśli istnieje) w tym wierszu „paskiem”, a następnie drukuje tę linię na standardowe wyjście i pętle.

W przypadku:

cat somefile | sed 's/foo/bar/'

Powłoka spawnuje proces kota i proces sed, a przewody stdout kota łączą ze stdin sed. Proces cat odczytuje z pliku kilka kilogramów, a może mega-bajtów, a następnie zapisuje je na standardowym wyjściu, gdzie sommand sed odbiera stamtąd, jak w drugim przykładzie powyżej. Podczas gdy sed przetwarza ten fragment, kot czyta inny fragment i zapisuje go w swoim standardzie, aby sed mógł dalej pracować.

Innymi słowy, dodatkowa praca wymagana przez dodanie catpolecenia to nie tylko dodatkowa praca polegająca na spawnowaniu dodatkowego catprocesu, ale także dodatkowa praca polegająca na odczytywaniu i zapisywaniu bajtów pliku dwa razy zamiast raz. Teraz, praktycznie rzecz biorąc i na nowoczesnych systemach, nie robi to wielkiej różnicy - może sprawić, że twój system wykona kilka mikrosekund niepotrzebnej pracy. Ale jeśli chodzi o skrypt, który planujesz rozpowszechnić, potencjalnie dla osób używających go na komputerach, które są już słabo zasilane, kilka mikrosekund może zsumować się z wieloma iteracjami.