Perché `tail -f … | grep -q …` chiude quando trova una corrispondenza?

Da StackOverflow post'grep -q' non esce con 'tail -f':

tail -f leggerà un file e visualizzerà le righe aggiunte successivamente, non si interromperà (a meno che non venga visualizzato un segnale come SIGTERM è inviato). grep non è la parte bloccante qui, tail -f è. grep leggerà dalla pipe finché non sarà chiusa, ma non lo sarà mai perché tail -f non si chiude e mantiene aperta la pipa.

Una soluzione al tuo problema sarebbe probabilmente (non testata e molto probabile che funzioni male):

tail -f logfile | while read line; do
  echo $line | grep -q 'find me to quit' && break;
done

Troverai maggiori informazioni e soluzioni nel post collegato.

grep esce e la pipe va via, anche se tail continua a correre. Questo registro delle segnalazioni di bug inizia con un caso d'uso molto simile al tuo:

Voglio usare tail e grep seguire un file fino a quando appare un modello particolare. Ma tail non esce quando grep è finito.

$ echo xxx > /tmp/blabla
$ tail -f /tmp/blabla |grep -m1 --line-buffered "xxx"
xxx

Ora tail prova ancora a leggere ed esce solo se scrivo di nuovo in /tmp/blabla .

È così che dovrebbe essere?

La spiegazione qui:

tail esce su SIGPIPE, tuttavia otterrà il segnale solo su write() , quindi devi ottenere più dati nel file prima di tail uscirà.

Per quanto ne so, questo meccanismo esatto è molto comune. Molti strumenti escono dopo provano a scrivere qualcosa su un tubo rotto, non è un bug.

Poi è arrivato questo desiderio:

È giusto però che tail , dal momento che può rimanere in giro per sempre, dovrebbe adottare misure speciali per rispondere all'allontanamento dell'altra estremità del tubo.

E infine:

Implementato in:
https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v8.27-42-gce0415f

E infatti, quando provo a riprodurre il tuo problema con tail da GNU coreutils 8.28, non posso. Lo strumento esce immediatamente.