Desde StackOverflow post'grep -q' no sale con 'tail -f':
tail -f leerá un archivo y mostrará las líneas agregadas posteriormente, no terminará (a menos que una señal como SIGTERM se ha enviado). grep no es la parte de bloqueo aquí, tail -f es. grep leerá desde la canalización hasta que se cierre, pero nunca lo hará porque tail -f no se cierra y mantiene la tubería abierta.
Una solución a su problema probablemente sería (no probado y muy probable que funcione mal):
tail -f logfile | while read line; do
echo $line | grep -q 'find me to quit' && break;
done
Encontrará más información y soluciones en la publicación vinculada.
grep sale y la tubería desaparece, aunque tail sigue corriendo Este registro de informe de errores comienza con un caso de uso muy similar al suyo:
Quiero usar tail y grep para seguir un archivo hasta que aparezca un patrón particular. Pero tail no sale cuando grep ha terminado.
$ echo xxx > /tmp/blabla
$ tail -f /tmp/blabla |grep -m1 --line-buffered "xxx"
xxx
Ahora tail todavía intenta leer y sale solo si vuelvo a escribir en /tmp/blabla .
¿Es así como se supone que debe ser?
La explicación allí:
tail sale en SIGPIPE, sin embargo, solo obtendrá la señal en write() , por lo que necesita obtener más datos en el archivo antes de tail saldrá.
Hasta donde yo sé, este mecanismo exacto es muy común. Muchas herramientas salen después intentan escribir algo en una tubería rota, no es un error.
Entonces vino este deseo:
Sin embargo, es un buen punto que tail , dado que puede quedarse para siempre, debe tomar medidas especiales para responder a la desaparición del otro extremo de la tubería.
Y finalmente:
Implementado en:
https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v8.27-42-gce0415f
Y, de hecho, cuando intento reproducir tu problema con tail de GNU coreutils 8.28, no puedo. La herramienta sale inmediatamente.