It's the same things as in:
In:
cmd1 | cmd2
Your shell happens to wait until cmd1
terminates even after cmd2
has already terminated. That's not the case of all shells. Some like the Bourne or Korn shell don't for instance.
When cmd2
dies, the pipe on cmd1
's stdout becomes broken, but that doesn't terminate cmd1
instantly.
cmd1
will terminate the next time it tries to write to that pipe. It will then receive a SIGPIPE whose default action is to terminate the process.
With cmd1
== tail -f file
and cmd2
== sed /w/q
, tail -f
will read the last 10 lines of the file and write them to stdout (the pipe), typically in one chunk unless the lines are really big and sit there waiting for more text to be appended to file
.
sed
, which runs concurrently, will wait for input on its stdin, read it, process it line by line and quit if there's a line that contains w
.
As soon (or possibly with a one-line delay with some sed
implementation) as it finds that line, it exits, but at that time, tail
has already written to the pipe all it had to WRITE, so it won't receive a SIGPIPE unless some additional text is added later on to the file (at which point it will do the fatal write()
).
If you wanted cmd1
to terminate as soon as cmd2
terminates, you'd need something to kill it once cmd2
terminates. Like with:
sh -c 'echo "$$"; exec tail -f test.txt' | {
IFS= read pid
sed /w/q
kill -s PIPE "$pid"
}
Or with bash
:
{ sed /w/q; kill -s PIPE "$!"; } < <(exec tail -f text.txt)
2020 Edit
As noted by @user414777, since version 8.28, the GNU implementation of tail
, in follow modes, now not only polls for new data in the file(s) it monitors but also checks whether its stdout becomes a broken pipe and exits straight away then (or within one second if inotify is not used), making those work arounds above unnecessary.
However note that only GNU tail
does this kind of processing, not any other implementation of tail
(AFAIK), and not any other utility (even the GNU implementations).
So, while:
tail -f file | head -n1
Will exit after one line,
tail -f file | tr '[:lower:]' '[:upper:]' | head -n1
for instance will not necessarily as tr
will not monitor whether its stdout becomes a broken pipe, and so will only die if it writes something there after the pipe has broken as usual (and it's only at that point that GNU tail -f
will exit).
tail -f
and asking why something in a previous answer doesn't work.tail -f
is not killed whensed
exits, when the pipe is broken (because it doesn't write anything after) and how to work around it.