tail
will die of a SIGPIPE signal as soon as it tries to write to the pipe when it has no reader.
So tail
will die soon after head
has finished outputting its 10000 lines and exited.
Because pipes can hold some data (64kiB on Linux) and because tail
buffers its output when not to a terminal (8kiB in my test) and head
and tail
read their input in chunks (of up to 8kiB in my tests), tail
may read up to 64 + 8 + 8 kiB after the end of the 10000th line after offset
before dying.
The worst case scenario is when head
is slower to empty the pipe than tail
is to fill it up (for instance if writing to a slow output like a terminal) and if the last byte of the 10000th line is at the start of a 8kiB block.
Then, in the end, head
will have read the block with that last newline at the beginning (8191 more bytes than necessary), but is busy writing its output. tail
, during that time has filled up the pipe (64kiB), has read another 8kiB block, but as the pipe is full is blocked writing to it. As soon as head
writes its last line, and exits, tail
will die but will have read 64kiB + 8 kiB + 8191 bytes past the last of those 10000 lines.
The best case scenario is when the last of the 10000 lines is at the very end of a 8kiB block and head
reads data as soon as it's put in the pipe by tail
. Then, if on the last block, head
manages to read it from the pipe and exit before tail
writes the next one, then tail
will die upon writing the next block, so it will read only 8192 bytes past the end of that 10000th line.
That assumes somefile
is a regular file. It could terminate sooner if somefile
was some king of special file that trickles one byte at a time for instance (like a pipe from a while :; do echo; done
)