Eine absolute Unsitte der man auch ständig in irgendwelchen Scripten begegnet. Was hat cat euch denn getan, dass es ständig unnötigerweise missbraucht wird?
Du musstest noch nie wirklich grottenalte Shell-Scripts debuggen weil sie selbst auf modernster Hardware Ewigkeiten mit sich selbst gespielt haben, stimmts? Wenn du dir die Zeiten mal ansiehst wirst du erkennen, dass die Ausführungsgeschwindigkeit ohne *cat* fast halbiert wurde.
Das war ein aus der Hand geschütteltes Beispiel mit 26 Dateien. Du wirst es nicht glauben, es gibt Systeme mit wesentlich mehr Dateien und zig Loops welche mit solchen Pipe-Orgien den Sauerstoffgehalt der Erde reduzieren. Das wirst du jetzt nicht verstehen. Ist auch nicht schlimm. Es gibt ja Leute die das wieder in Ordnung bringen.
Kannst du auch machen: grep foo bar < bar grep foo
Ich bin kein Shell-Experte, aber es hat halt meines Wissens Nachteile. Zunächst einmal wird durch < nicht cat aufgerufen, sondern es handelt sich typischerweise um eine Shell-Funktion, wobei ich mir vorstellen könnte, dass manche Shells in so einem Fall auch cat aufrufen, wer weiß. Dazu kommt, dass du wesentlich effizienter eine Dateiliste aufbauen. Kannst du mittels < prinzipiell auch, aber das wird tendenziell sehr sehr unübersichtlich.
Dennoch kann es sehr hilfreich sein, da du es mit einer Pipe kombinieren kannst, was bei der "normalen" Dateiübergabe typischerweise nicht möglich ist: ... foo |
Das würde die Ausgabe von ... foo sowie die Datei foo2 nach bar "greppen". Ist sicher nicht der Standardfall, aber ich kann mir schon vorstellen, dass es in der einen oder anderen Situation nützlich sein kann.
Da hast du wohl Recht. Aber wer kann sich schon merken, in welcher Reihenfolge die Parameter von grep stehen müssen. Außerdem ist cat * | grep irgendwas schon ein Unterschied zu grep irgendetwas * . Da bräuchte man schon grep irgendetwas * | sed s/.*:// oder irgendeinen Parameter von grep, den man sich noch viel schwerer merken kann.
Ich sehe wenig Sinn drin, mir die Ausgaben von "rpm", "zypper" oder anderen Programmen in eine Datei schreiben zu lassen, wenn ich nur eine Sache daraus brauche, z.B. wenn ich ein Programm oder eine Datei suche. Da nehme ich less um bei recht einfachen Begriffen auch noch die Übersicht zu behalten. Klar, ich könnte den Puffer meines Terminals vergrößern, aber will ich das? less erfüllt hier seinen Zweck. Ich erachte es also keineswegs als Unsitte an.
Wenn du Performance willst, solltest du vielleicht kein Shellscript verwenden, sondern gleich auf C umsteigen. Die Zeit, die du damit sparst ist so gering, dass es sich nicht lohnt.
Wo stand etwas von der Unsitte *less* zu verwenden? Da stand etwas von *cat* als Paradebeispiel für die teilweise ausufernden Pipe-Orgien in Shell-Scripten. Und diese Pipe-Orgien zu beseitigen bzw. zu minimieren bringt durchaus schon mal Geschwindigkeitgewinne von 80-90%.
Auf C umzusteigen bringt in diesem Falle garnichts. Wer solche Shell-Scripte hinzaubert bekommt auch keine effizienten Programme in C gebacken.
cat dateiname | grep suchmuster | less
Eine absolute Unsitte der man auch ständig in irgendwelchen Scripten begegnet. Was hat cat euch denn getan, dass es ständig unnötigerweise missbraucht wird?
cat datei | awk irgendwas -> awk irgendwas < datei
cat datei | grep irgendwas -> grep irgendwas datei
Vielleicht wird es als lesbarer erachtet die Datei zuerst zu schreiben.
Nur werden durch diese Art "lesbaren" Codes Shell-scripte schnarchlangsam.
Gerade mal in einem Verzeichnis mit 26 C-Dateien getestet.
# time for i in *.c; do cat $i|grep -q "for"; done
real 0m0.111s
user 0m0.019s
sys 0m0.095s
# time for i in *.c; do grep -q "for" $i; done
real 0m0.068s
user 0m0.012s
sys 0m0.040s
Skandalös, da muss der User ganze 0,05 Sek länger warten !
Du musstest noch nie wirklich grottenalte Shell-Scripts debuggen weil sie selbst auf modernster Hardware Ewigkeiten mit sich selbst gespielt haben, stimmts? Wenn du dir die Zeiten mal ansiehst wirst du erkennen, dass die Ausführungsgeschwindigkeit ohne *cat* fast halbiert wurde.
Das war ein aus der Hand geschütteltes Beispiel mit 26 Dateien. Du wirst es nicht glauben, es gibt Systeme mit wesentlich mehr Dateien und zig Loops welche mit solchen Pipe-Orgien den Sauerstoffgehalt der Erde reduzieren. Das wirst du jetzt nicht verstehen. Ist auch nicht schlimm. Es gibt ja Leute die das wieder in Ordnung bringen.
Kannst du auch machen:
grep foo bar
< bar grep foo
Ich bin kein Shell-Experte, aber es hat halt meines Wissens Nachteile. Zunächst einmal wird durch < nicht cat aufgerufen, sondern es handelt sich typischerweise um eine Shell-Funktion, wobei ich mir vorstellen könnte, dass manche Shells in so einem Fall auch cat aufrufen, wer weiß.
Dazu kommt, dass du wesentlich effizienter eine Dateiliste aufbauen. Kannst du mittels < prinzipiell auch, aber das wird tendenziell sehr sehr unübersichtlich.
Dennoch kann es sehr hilfreich sein, da du es mit einer Pipe kombinieren kannst, was bei der "normalen" Dateiübergabe typischerweise nicht möglich ist:
... foo |
Das würde die Ausgabe von ... foo sowie die Datei foo2 nach bar "greppen".
Ist sicher nicht der Standardfall, aber ich kann mir schon vorstellen, dass es in der einen oder anderen Situation nützlich sein kann.
Ok, jetzt hat es mir da das Beispiel verhauen. Sollte
... foo | < foo2 grep bar
sein
Da hast du wohl Recht. Aber wer kann sich schon merken, in welcher Reihenfolge die Parameter von grep stehen müssen.
Außerdem ist cat * | grep irgendwas schon ein Unterschied zu grep irgendetwas * . Da bräuchte man schon grep irgendetwas * | sed s/.*:// oder irgendeinen Parameter von grep, den man sich noch viel schwerer merken kann.
Ich sehe wenig Sinn drin, mir die Ausgaben von "rpm", "zypper" oder anderen Programmen in eine Datei schreiben zu lassen, wenn ich nur eine Sache daraus brauche, z.B. wenn ich ein Programm oder eine Datei suche. Da nehme ich less um bei recht einfachen Begriffen auch noch die Übersicht zu behalten. Klar, ich könnte den Puffer meines Terminals vergrößern, aber will ich das? less erfüllt hier seinen Zweck. Ich erachte es also keineswegs als Unsitte an.
Wenn du Performance willst, solltest du vielleicht kein Shellscript verwenden, sondern gleich auf C umsteigen. Die Zeit, die du damit sparst ist so gering, dass es sich nicht lohnt.
Wo stand etwas von der Unsitte *less* zu verwenden? Da stand etwas von *cat* als Paradebeispiel für die teilweise ausufernden Pipe-Orgien in Shell-Scripten. Und diese Pipe-Orgien zu beseitigen bzw. zu minimieren bringt durchaus schon mal Geschwindigkeitgewinne von 80-90%.
Auf C umzusteigen bringt in diesem Falle garnichts. Wer solche Shell-Scripte hinzaubert bekommt auch keine effizienten Programme in C gebacken.
Oh, da war ich mit dem Antworten wohl etwas voreilig. Dann nehme ich zurück was ich gesagt habe.
Heißt "grep" heutzutage nicht "ack"? (oder "ack-grep", je nach System)