[PATCH] Suppress tr's stderr in the generate function

[Allan Odgaard]

On 28 Dec 2020, at 11:32, Nicolai Dagestad wrote:

> It might be something fishy with my machine, with:
> 	python -c "print('0'*4097)" | tr 0 1 | head -c 10
> I get the broken pipe on my laptop, but on none of my other machines 
> running arch...

Background:

In the above line `head` reads 10 bytes and then closes its stdin (which 
is stdout for `tr`).

When a program writes to a closed pipe (stdout), it will receive SIGPIPE 
which by default will terminate the process, so normally `tr` will be 
terminated (silently) when nobody reads its output.

The reason for the 4096 bytes is due to buffering, `tr` can succesfully 
fill up the buffer before triggering a SIGPIPE signal.

One can set SIGPIPE to be ignored, this will be inherited by a child 
process during fork.

If SIGPIPE is being ignored, then it looks very much like `tr` *will* 
output an error message, as then `fwrite` will fail and output an error 
judging by this code: 
https://github.com/coreutils/coreutils/blob/fb64712c4d79a542bae533034c6c4802eae555fd/src/tr.c#L1585-L1587

My theory: Someone has set SIGPIPE to be ignored, for the process that 
spawns `pass` (and your test).

Can you give some more information about your execution environment? Is 
this a terminal? Maybe try relaunch it and/or reboot.

Or perhaps make a test executable that sets SIGPIPE back to default and 
then execute `pass` from that process.