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.
