Diese andere Antwort ist etwas mangelhaft. Der Befehl lautet
find . -name '*.txt' | head -n 3
Dann gibt es eine Erklärung in einem der Kommentare :
headstartet und wartet auf Eingabe von der linken Seite der Leitung. Dann findstartet und sucht nach Dateien, die den Kriterien entsprechen, dessen Ausgang durch die Leitung zu senden. Wenn headdie Anzahl der angeforderten Zeilen empfangen und gedruckt wurde, wird die Pipe geschlossen. findbemerkt das geschlossene Rohr und es endet auch. Einfach, elegant und effizient .
Das ist fast wahr.
Das Problem ist find, dass die geschlossene Pipe nur beim Versuch, darauf zu schreiben, bemerkt wird. In diesem Fall wird die 4. Übereinstimmung gefunden. Aber wenn es kein viertes Match gibt, findgeht es weiter. Deine Muschel wird warten! Wenn dies in einem Skript geschieht, wartet das Skript, obwohl wir bereits wissen, dass die Pipe-Ausgabe endgültig ist und nichts hinzugefügt werden kann. Nicht so effizient.
Der Effekt ist vernachlässigbar, wenn dieser findVorgang von selbst schnell abgeschlossen wird. Bei einer komplexen Suche in einem großen Dateibaum kann der Befehl jedoch unnötig verzögern, was auch immer Sie als Nächstes tun möchten.
Die nicht ganz perfekte Lösung ist das Laufen
( find … & ) | head -n 3
Auf diese Weise headwird die Shell beim Beenden sofort fortgesetzt. Der Hintergrundprozess findkann dann ignoriert werden (er wird früher oder später beendet) oder mit pkilloder etwas gezielt ausgeführt werden .
Um das Konzept zu beweisen, können Sie suchen /. Wir erwarten nur ein Spiel, findsuchen es aber überall und es kann viel Zeit in Anspruch nehmen.
find / -wholename / 2>/dev/null | head -n 1
Beenden Sie es mit Ctrl+ C, sobald Sie das Problem sehen. Jetzt vergleiche:
pidof find ; ( find / -wholename / 2>/dev/null & ) | head -n 1 ; pidof find
find . -name '*.txt' -print -quitnur die erste Übereinstimmung anzeigen undfindnach der ersten Übereinstimmung beenden. Ich weiß nicht, ob es möglich ist, sich an den Fall "Ausfahrt nach n Übereinstimmungen" anzupassen.