tail morrerá de um sinal SIGPIPE assim que tentar gravar no pipe quando não tiver leitor.
Então tail morrerá logo após head ter finalizado suas 10000 linhas e sair.
Porque os pipes podem conter alguns dados (64kiB no Linux) e porque tail armazena sua saída quando não está em um terminal (8kiB no meu teste) e head e tail lêem sua entrada em blocos (de até 8kiB em meus testes), tail pode ler até 64 + 8 + 8 kiB após o fim da linha 10000 depois de offset antes de morrer.
O pior cenário é quando head é mais lento para esvaziar o canal do que tail é preenchê-lo (por exemplo, se gravar em uma saída lenta como um terminal) e se o último byte da linha 10000 é no início de um bloco 8kiB.
Em seguida, no final, head terá lido o bloco com a última nova linha no início (8191 bytes a mais do que o necessário), mas está ocupado escrevendo sua saída. tail , durante esse tempo preencheu o pipe (64kiB), leu outro bloco 8kiB, mas como o pipe está cheio está bloqueado escrevendo para ele. Assim que head escrever sua última linha e sair, tail morrerá, mas terá lido 64kB + 8 kiB + 8191 bytes após a última dessas 10.000 linhas.
O melhor cenário é quando a última das 10000 linhas está no final de um bloco de 8kiB e head lê os dados assim que é colocado no canal por tail . Então, se no último bloco, head conseguir lê-lo a partir do pipe e sair antes de tail escrever o próximo, então tail irá morrer ao escrever o próximo bloco, então ele lerá apenas 8192 bytes após o fim dessa linha 10000.
Isso pressupõe que somefile seja um arquivo comum. Ele poderia terminar mais cedo se somefile fosse algum arquivo especial que goteja um byte de cada vez, por exemplo (como um pipe de um while :; do echo; done )