batman test fails on Linux

[lilyball]

Running the batman test suite fails on Linux with signal 141 (SIGPIPE). It appears that batman --version | head -n1 causes batman to fail on a printf call.

[lilyball]

Same issue with the prettybat test too.

[eth-p]

Thanks for the heads up! I'll check it out and try to fix it soon.

Update:
This doesn't appear to be consistently reproducible (race condition?), and it might take a while to figure out.

[eth-p]

After some research, it seems that head likes to send SIGPIPE when it's done reading, which Bash is more than happy to consider a fatal error with set -o pipefail. I'm surprised I didn't encounter this when writing the tests, but I believe it should be fixed now with e79e747.

Try running ./test.sh --verbose --compiled --suite prettybat a few times (I did 50 to make sure, but 15 or so would probably work), and let me know if that solved your issue.

[sharkdp]

it seems that head likes to send SIGPIPE when it's done reading,

more precisely, when head is done reading, it closes its STDIN, which is connected to your STDOUT. The kernel then sends SIGPIPE to your process if you are trying to write into the closed pipe. This often needs to be handled correctly. In bat, we simply exit with success (code 0): https://github.com/sharkdp/bat/blob/38c096bf7908f762fa1a79a696f1212e52651e36/src/error.rs#L19-L23

[lilyball]

I ran the batman and prettybat test suites 20 times each and got zero failures, so I think it worked.

More generally, either ignoring the return code of printf or exiting cleanly if it reports code 141 would be better.

[eth-p]

I ran the batman and prettybat test suites 20 times each and got zero failures, so I think it worked.

Good to know!

More generally, either ignoring the return code of printf

The issue wasn't so much the printf call from inside the bat* script, as much as it was the testing framework which used set -e along with set -o pipefail, which—as I just learned—doesn't play nicely with head. For the scripts themselves, I think it would be reasonable to expect them to fail with a nonzero exit if they can't print an error message.

or exiting cleanly if it reports code 141 would be better.

The testing framework doesn't support this feature yet, but it's definitely something I should be thinking about adding support for.