GNU bug report logs - #54035
Patch for easier use in scripting pipelines

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#54035: closed (Patch for easier use in scripting pipelines)
Date: Thu, 24 Feb 2022 19:10:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 24 Feb 2022 11:09:05 -0800
with message-id <7c398c12-dba7-88f9-9d06-aa15b1d3a48e <at> cs.ucla.edu>
and subject line Re: bug#54035: Patch for easier use in scripting pipelines
has caused the debbugs.gnu.org bug report #54035,
regarding Patch for easier use in scripting pipelines
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
54035: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=54035
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ulrich Eckhardt <ulrich.eckhardt <at> base-42.de>
To: bug-grep <at> gnu.org
Subject: Patch for easier use in scripting pipelines
Date: Thu, 17 Feb 2022 08:57:10 +0100

[Message part 3 (text/plain, inline)]

Greetings!

The attached patch add a `--pipe` option to grep. When used, grep
only exits with with nonzero status on error. In particular, it
doesn't signal "match" / "no match" through the exit code.

Here's an example using Bash:

  # enable automatic error handling
  set -eo pipefail
  # grep for issues in a logfile to produce a report
  cat logfile | grep issue | sort --unique

If grep doesn't find "issue" in its input (which is not an error,
obviously), it exits with status 1. Bash interprets this nonzero exit
code as an error and terminates with an error itself.

In order to fix that bug in the above script, you currently have to
replace `grep ...` with `grep ... || [ $? = 1 ]`, which is not really
readable. As alternative, I've implemented a `--pipe` option, which
only returns nonzero on actual errors, but not when there is no match.
This is a bit of a complementary option to `--quiet`.

Open tasks here:
 * FSF paperwork is not finished, so obviously the patch can't be
   applied yet.
 * Should I add a `-p` to complement the long `--pipe`?
 * Should I call it `--pipe` at all? The other alternative I came up
   with was `--filter`. I don't really like either of them very much.


Cheers!

Uli

[gnu-grep-pipe-option.patch (text/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ulrich Eckhardt <ulrich.eckhardt <at> base-42.de>
Cc: 54035-done <at> debbugs.gnu.org
Subject: Re: bug#54035: Patch for easier use in scripting pipelines
Date: Thu, 24 Feb 2022 11:09:05 -0800

[Message part 6 (text/plain, inline)]

On 2/23/22 23:11, Ulrich Eckhardt wrote:

> Just for my understanding, grep stops reading
> when it finds the first match and then the shell closes the output
> stream of cat. That in turn causes cat to fail (exit code 141, meaning
> SIGPIPE), because it can't write the rest of the data that it wants,
> right?

Right.

> I think that short reads (which could cause SIGPIPE) and the
> non-error exit code 1 deserve mention there. I'll take a look and
> perhaps file another patch.

I installed the attached to try to document this better.

[0001-doc-mention-issues-with-set-e.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.