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

From: [email-masked]
Date: Fri, 06 Dec 2024 18:21:11 -0600

Frank wrote:
>> The real reason seems to be (... is), that a proper match seems
>> to kill the pipe early with exitcode 141 

Placing the X= setting inside the key line in the code, we see it says:

if echo "$( cat "${TMPOUT}" 2>/dev/null ) | grep -q "^${V}$"; then

Looking at the grep(1) man page entry for its "-q" option, we see it says:

      -q, --quiet, --silent
             Quiet; do not write anything to standard output.  Exit immediately
             with zero status if any if any match is found, even if an error was
             detected.  Also see  the  -s  or  --no-messages option.

So we have an "if" statement testing the exit value of a pipe of 'echo' to 'grep'
where the 'grep' will exit early, if it finds a match early.  As a secondary
matter of efficiency, we also have the contents of TMPOUT filling the value
of shell's formulation of the argument to be passed to echo'd into a pipe,
 instead of directly grep'ing in TMPOUT.

If for some reason I don't see off hand, you prefer to remain with this inefficient
"echo contents_of_TMPOUT | grep ..." construct, I'd suggest using "grep -c"
instead of "grep -q", then checking for a positive count, thus forcing the entire
contents of TMPOUT to be read and echo'd, before the grep decides it can
exit early and break the pipe:

if [[ $(echo "$( cat "${TMPOUT}" 2>/dev/null ) | grep -c "^${V}$") -gt 0 ]]; then

Or, more efficiently, just "grep -q" directly in TMPOUT and skip the echo and
pipe entirely:

if grep -q "^${V}$" "${TMPOUT}"; then

-- 
  Paul Jackson
  [email-masked]