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]:
head
si avvia e attende l'input dal lato sinistro del tubo. Quindi si find
avvia e cerca i file che soddisfano i criteri specificati, inviandone l'output attraverso la pipe. Quando head
ha ricevuto e stampato il numero di righe richieste, termina chiudendo il tubo. find
nota il tubo chiuso e termina anche. Semplice, elegante ed efficiente .
Questo è quasi vero.
Il problema è find
notare 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 find
continuerà. 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 find
finisce 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 head
esce, la shell continua immediatamente. Il find
processo in background può quindi essere ignorato (uscirà prima o poi) o mirato pkill
o qualcosa del genere.
Per dimostrare il concetto che potresti cercare /
. Ci aspettiamo una sola partita, ma la cerchiamo find
ovunque 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 -quit
solo mostrare la prima partita e lasciarefind
uscire dopo la prima partita. Non so se sia possibile adattarsi al caso "esci dopo aver trovato n corrispondenze".