Sollte ich mich um unnötige Katzen kümmern?

Viele Befehlszeilenprogramme können ihre Eingabe entweder über eine Pipe oder als Dateinamenargument verwenden. Bei langen Shell-Skripten ist das Starten der Kette mit einem catbesser lesbar, insbesondere wenn der erste Befehl mehrzeilige Argumente benötigt.

Vergleichen Sie

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

und

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

Ist die letztere Methode weniger effizient? Wenn ja, ist der Unterschied ausreichend, um zu berücksichtigen, ob das Skript beispielsweise einmal pro Sekunde ausgeführt wird? Der Unterschied in der Lesbarkeit ist nicht groß.

Die "endgültige" Antwort wird Ihnen natürlich von The Useless Use of catAward gebracht .

Der Zweck von cat besteht darin, Dateien zu verketten (oder "zu verketten"). Wenn es sich nur um eine Datei handelt, ist das Verketten mit nichts Zeitverschwendung und kostet Sie einen Prozess.

Wenn Sie cat instanziieren, damit Ihr Code anders gelesen wird, ist dies nur ein weiterer Prozess und eine weitere Reihe von Eingabe- / Ausgabestreams, die nicht benötigt werden. Normalerweise wird der eigentliche Stillstand in Ihren Skripten in ineffizienten Schleifen und aktueller Verarbeitung liegen. Auf den meisten modernen Systemen wird eine zusätzliche catLeistung Ihre Leistung nicht beeinträchtigen, aber es gibt fast immer eine andere Möglichkeit, Ihren Code zu schreiben.

Wie Sie bemerken, können die meisten Programme ein Argument für die Eingabedatei akzeptieren. Es gibt jedoch immer die eingebaute Shell <, die überall dort verwendet werden kann, wo ein STDIN-Stream erwartet wird, der Ihnen einen Prozess erspart, indem Sie die Arbeit in dem Shell-Prozess ausführen, der bereits ausgeführt wird.

Sie können sogar kreativ werden, wo Sie es schreiben. Normalerweise wird es am Ende eines Befehls platziert, bevor Sie Ausgabeumleitungen oder Pipes wie folgt angeben:

sed s/blah/blaha/ < data | pipe

Das muss aber nicht so sein. Es kann sogar zuerst kommen. Zum Beispiel könnte Ihr Beispielcode so geschrieben werden:

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

Wenn die Lesbarkeit von Skripten Ihr Anliegen ist und Ihr Code so unübersichtlich ist, dass das Hinzufügen einer Zeile für catdas Verfolgen einfacher wird, gibt es andere Möglichkeiten, Ihren Code zu bereinigen. Eines, das ich häufig verwende, um Skripte später leichter herauszufinden, ist das Aufteilen von Pipes in logische Mengen und das Speichern in Funktionen. Der Skriptcode wird dann sehr natürlich und jeder Teil der Pipline ist leichter zu debuggen.

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

fix_blahs < data

Sie könnten dann fortfahren fix_blahs < data | fix_frogs | reorder | format_for_sql. Eine Pipleline, die so liest, ist wirklich einfach zu befolgen, und die einzelnen Komponenten können problemlos in ihren jeweiligen Funktionen debuggt werden.

Hier ist eine Zusammenfassung einiger der Nachteile von:

cat $file | cmd

Über

< $file cmd

• Zunächst ein Hinweis: Es fehlen (absichtlich zum Zwecke der Diskussion) oben doppelte Anführungszeichen $file. Im Falle von catist das immer ein Problem, mit Ausnahme von zsh; Bei der Umleitung ist dies nur ein Problem für bashoder ksh88, bei einigen anderen Shells nur dann, wenn sie interaktiv sind (nicht in Skripten).
• Der am häufigsten genannte Nachteil ist der zusätzliche Prozess, der erzeugt wird. Beachten Sie, dass, wenn cmdes eingebaut ist, dies in einigen Shells sogar 2 Prozesse sind bash.
• Immer noch auf der Performance-Front, außer in Shells, in denen cates eingebaut ist, wird auch ein zusätzlicher Befehl ausgeführt (und natürlich geladen und initialisiert (und auch die Bibliotheken, mit denen er verknüpft ist)).
• Bei großen Dateien bedeutet dies, dass das System die catund cmd-Prozesse abwechselnd einplanen und den Pipe-Puffer ständig auffüllen und leeren muss. Auch wenn cmdtut 1GBgroße read()Systemaufrufe zu einer Zeit, wird die Steuerung muß hin und her zwischen gehen catund cmdweil ein Rohr kann nicht mehr als ein paar Kilobyte Daten zu einer Zeit halten.
• Einige cmds (wie wc -c) können einige Optimierungen vornehmen, wenn ihr stdin eine reguläre Datei ist, mit der sie nichts cat | cmdanfangen können, da ihr stdin dann nur eine Pipe ist. Mit catund einer Pipe bedeutet dies auch, dass sie nicht seek()in der Datei enthalten sein können. Bei Befehlen wie tacoder tailmacht dies einen großen Unterschied in der Leistung, da bei diesen Befehlen catdie gesamte Eingabe im Speicher abgelegt werden muss.
• Die cat $fileund sogar die korrektere Version cat -- "$file"funktionieren nicht richtig für bestimmte Dateinamen wie -( --helpoder alles, was mit beginnt, -wenn Sie die vergessen --). Wenn man darauf besteht cat, sollte man aus cat < "$file" | cmdGründen der Zuverlässigkeit wahrscheinlich stattdessen verwenden.
• Wenn $filees nicht zum Lesen geöffnet werden kann (Zugriff verweigert, existiert nicht ...), < "$file" cmdwird eine konsistente Fehlermeldung (von der Shell) gemeldet und nicht ausgeführt cmd, während cat $file | cmdes weiterhin ausgeführt wird cmd, wobei die Standard-ID wie eine leere Datei aussieht. Das bedeutet auch, dass in Sachen < file cmd > file2, file2wenn nicht geöffnet werden filekann , nicht überladen wird .

Das Platzieren <fileam Ende einer Pipeline ist weniger lesbar als cat fileam Anfang. Natürliches Englisch liest von links nach rechts.

Den <fileStart der Pipeline zu setzen ist auch weniger lesbar als cat, würde ich sagen. Ein Wort ist besser lesbar als ein Symbol, insbesondere ein Symbol, das in die falsche Richtung weist.

Mit wird catdas command | command | commandFormat beibehalten .

Eine Sache, die die anderen Antworten hier offenbar nicht direkt angesprochen haben, ist, dass eine solche Verwendung catnicht "nutzlos" ist in dem Sinne, dass "ein irrelevanter Katzenprozess entsteht, der keine Arbeit leistet". Es ist in dem Sinne nutzlos, dass "ein Katzenprozess erzeugt wird, der nur unnötige Arbeit leistet".

Im Fall dieser beiden:

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

Die Shell startet einen sed-Prozess, der von somefile oder stdin (bzw.) liest, und führt dann eine Verarbeitung durch - sie liest, bis sie eine neue Zeile erreicht, ersetzt das erste 'foo' (falls vorhanden) in dieser Zeile durch 'bar' und druckt dann diese Linie zu stdout und Schleifen.

Im Falle des:

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

Die Muschel erzeugt einen Katzenprozess und einen Sed-Prozess und verdrahtet den Standard der Katze mit dem Standard der Sed. Der cat-Prozess liest einen Teil von mehreren Kilo- oder vielleicht Megabyte aus der Datei und schreibt ihn dann in seine Standardausgabe, in der der sed-Befehl wie im obigen zweiten Beispiel von dort abhebt. Während sed diesen Chunk verarbeitet, liest cat einen weiteren Chunk und schreibt ihn in seine Standardausgabe, damit sed als nächstes daran arbeiten kann.

Mit anderen Worten, die zusätzliche Arbeit, die durch das Hinzufügen des catBefehls erforderlich ist, ist nicht nur die zusätzliche Arbeit, einen zusätzlichen catProzess zu erzeugen , sondern auch die zusätzliche Arbeit, die Bytes der Datei zweimal statt einmal zu lesen und zu schreiben. In der Praxis und auf modernen Systemen macht dies keinen großen Unterschied - es kann dazu führen, dass Ihr System einige Mikrosekunden unnötiger Arbeit leistet. Wenn es sich jedoch um ein Skript handelt, das Sie verteilen möchten, möglicherweise an Personen, die es auf Computern verwenden, die bereits nicht ausreichend ausgelastet sind, können sich einige Mikrosekunden über viele Iterationen summieren.