Quest'altra risposta è in qualche modo imperfetta. Il comando è
find . -name '*.txt' | head -n 3
Quindi c'è una spiegazione in uno dei commenti [enfasi mia]:
headsi avvia e attende l'input dal lato sinistro del tubo. Quindi si findavvia e cerca i file che soddisfano i criteri specificati, inviandone l'output attraverso la pipe. Quando headha ricevuto e stampato il numero di righe richieste, termina chiudendo il tubo. findnota il tubo chiuso e termina anche. Semplice, elegante ed efficiente .
Questo è quasi vero.
Il problema è findnotare la pipe chiusa solo quando tenta di scrivere su di essa - in questo caso è quando viene trovata la 4a corrispondenza. Ma se non c'è la quarta partita, allora findcontinuerà. La tua shell aspetterà! Se accade in uno script, lo script attenderà, nonostante sappiamo già che l'output della pipe è definitivo e non è possibile aggiungere nulla. Non così efficiente.
L'effetto è trascurabile se questo particolare findfinisce velocemente da solo, ma con una ricerca complessa in un grande albero di file il comando potrebbe ritardare inutilmente qualsiasi cosa tu voglia fare dopo.
La soluzione non così perfetta è quella di correre
( find … & ) | head -n 3
In questo modo quando headesce, la shell continua immediatamente. Il findprocesso in background può quindi essere ignorato (uscirà prima o poi) o mirato pkillo qualcosa del genere.
Per dimostrare il concetto che potresti cercare /. Ci aspettiamo una sola partita, ma la cerchiamo findovunque e potrebbe richiedere molto tempo.
find / -wholename / 2>/dev/null | head -n 1
Terminalo con Ctrl+ Cnon appena vedi il problema. Ora confronta:
pidof find ; ( find / -wholename / 2>/dev/null & ) | head -n 1 ; pidof find
find . -name '*.txt' -print -quitsolo mostrare la prima partita e lasciarefinduscire dopo la prima partita. Non so se sia possibile adattarsi al caso "esci dopo aver trovato n corrispondenze".