Behaviour when grep is not GNU grep is not user-friendly & in some cases fails to trigger stream poisoning

[h4l]

As seen in #10, when running on a platform which doesn't use GNU grep, the coproc can fail with an unhelpful error. It's also a bug in that it doesn't trigger the stream poisoning behaviour, so a downstream json/jb call may not notice the error.

Usually when the coproc fails, _PID is set, and we do indicate that the coproc process terminated unexpectedly and do trigger stream poisoning.

Seems like we need a few things:

• Be able to use a different command then grep so that ggrep or some other path could be used
• Show a meaningful error if the coproc fails to start.
  • Note: Initial experimentation indicates that the coproc _PID var is usually set even if the executable exits (e.g. /bin/false), but it seems like there's the potential for timing to mess this up — inserting sleep 0 after a failed coproc results in the _PID not being set after the sleep.
• Maybe try ggrep by default if grep fails; I think this is a common default for GNU grep when installed. e.g. Homebrew does this, and I think Solaris too.
  • Maybe an envar to specify a grep command could allow specifying multiple alternatives, like PATH