bug#74699: need valid explanation / weird 'grep -q' behaviour

[Frank Reppin]

Dear all, hi Paul,

yeah, you're right - thankyou for your feedback.

In the meanwhile - it is more clear to me...
... especially after re-reading what others suspected on
stackoverflow.

The real reason seems to be (... is), that a proper match seems
to kill the pipe early with exitcode 141 - and thus making
the pipe as a whole fail - as one would expect when using 'pipefail'.
(although - to be honest - I didn't thought of exactly such a fail when
it comes to use grep with '-q' in such cases).

However - it thus turns out to be OK. One just has to be cautious
when using it in this way...
... not sure if it's maybe worth mentioning in the manpage?!
(that pipefail or other returncode checking mechanisms should be aware
of this fact - for the unaware).

cheers,
FR




On 05.12.2024 20:59, Paul Eggert wrote:
> On 2024-12-04 15:43, Frank Reppin wrote:
> > Some claim that this is due to 'set -o pipefail' beeing used in the 
> > script... but this does not really explain why it only _sometimes_ 
> > happens.
>
> I don't see why not. Pipe buffering is an "it all depends" situation.
>
> Anyway, I tried your script on bleeding-edge grep on Fedora 40 and it 
> worked fine for me. You didn't mention your grep version; behavior in 
> this area changed in 2016, though I doubt your version is that old.
>
> One workaround is to use "set -o pipefail" only for pipelines where you 
> want the entire pipeline to fail merely because one component failed.

--
43rd Law of Computing:
        Anything that can go wr
fortune: Segmentation violation -- Core dumped