Oh and, ...
On Mon, 28 Nov 2022, Pádraig Brady wrote:
I'm presuming the input generator is depending on the compiler runs
(written to by tee) to exit cleanly, before exiting / generating more?
Hence the hangs?
If that was the case then there still might be the potential for hangs
even if tee detected closed pipes. I.e. if the compiler runs hung rather
than exited, this not be distinguishable from tee as the pipe outputs
would remain.
This is a good point too.
So perhaps the generally useful cases are (1) if the intermittent input is
from a tty, but also (2) if the input program (that writes to a pipe) has
similar logic to what we are proposing to add to tee here; ie, that it
detects when its output becomes a broken pipe.
More generally for (2), if the whole command pipeline is written that way,
this will propagate all the way back. In that sense there might even be
some merit in adding this type of logic to all coreutils programs that
filter stdin to stdout.
For instance, take this oversimplified example with cat:
cat | cat | cat | cat | true
If this is run on a terminal, you have to hit Enter *4 times* before
control returns to the shell, as it takes that many separate writes to
cause all the pipes to break in sequence (right-to-left) and finally get
the write failure in the left-most cat.
If this kind of detect-broken-output-pipe logic were added to filter utils
generally, the above example (with 4 cats) would return to the shell
immediately.