Re: Does head util cause SIGPIPE?

[Kaz Kylheku (Coreutils)]

On 2019-10-25 00:56, Ray Satiro wrote:
> Recently I tracked down a delay in some scripts to this line:
>
> find / -name filename* 2>/dev/null | head -n 1

(Here 'filename*' should be quoted, because we want find
to process the pattern, not for the shell to try to expand it.)

Interestingly, POSIX neglects to say whether head is required to
quit after dumping the required number of lines, or whether it
terminates (thereby abruptly closing its standard input, possibly
causing a broken pipe error in the upstream process).

(Of course head can be given two or more file arguments, in
which case of course it doesn't quit until the last one is processed.)

In a RATIONALE paragraph, though POSIX says that head, for a
single file, could be simulated using "sed 10q"; and that *will*
quit immediately and break the pipe.

> It appeared that the searching continued after the first result was
> found. I expected head would terminate and SIGPIPE would be sent which
> would cause find to terminate, but that did not happen.

> Since I was in
> cygwin I thought maybe it was a Windows issue but I tried in Ubuntu 16

SIGPIPE not working in Cygwin cannot possibly be a "Windows issue",
since Windows has no such thing as SIGPIPE; it would be a Cygwin issue.

> with an aribtrary file and noticed the same thing.

I don't see it in Unbuntu 16 or 18 at all. "find / | head" shows ten
lines, and after that, there is no evidence of any find process
continuing to execute. If I run:

   find / | head && ps -aux | grep find

the grep process only finds itself in the output of ps; I tried about
20 times in a row, hoping to catch a briefly lingering find, but
nothing.