`pipefail` and `grep -q` wont get along well

[redbaron]

My colleague @james-masson found an interesting problem when set -o pipefail is combined with grep -q and the input to grep is produced in small chunks (like reasonably short line at a time). This combination leads to race condition when process producing input to grep may or may not receive SIGPIPE and therefore may or may not produce non 0 exit code.

#!/bin/bash

set -e
set -o pipefail

while true
do
ip route  | grep -q "." 
echo "done"
done

it would be awesome if shellcheck warned about it, because in general case combination of pipefail and grep -q can not produce consistent results

[dougpagani]

I came across a similar point of confusion, where this was causing strange behavior on: if ( unzip -Z1 archive.zip | grep -q file.csv ), having set set -euo pipefail, as I do most of my scripts. It is an interesting combination of special cases, especially because if you run it in interactive mode in trying to debug/sanity-check, you'll never come across an error at all, and in script-mode, PIPEFAIL [141] is more-or-less "silent". Thankfully I had an in-prompt $? printer, otherwise I'd have spent a few hours more banging my head against completely irrelevant parts of my code.

[AndrewDDavis]

A combination of the pipefail shell option and piping to head produces a similar problem.