bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54035: Patch for easier use in scripting pipelines


From: Ulrich Eckhardt
Subject: bug#54035: Patch for easier use in scripting pipelines
Date: Fri, 18 Feb 2022 09:27:15 +0100

On Thu, 17 Feb 2022 19:05:45 -0800
Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 2/16/22 23:57, Ulrich Eckhardt wrote:
> > In order to fix that bug in the above script, you currently have to
> > replace `grep ...` with `grep ... || [ $? = 1 ]`, which is not
> > really readable.
> 
> Actually, appending something "|| test $? -eq 1" looks readable to
> me; plus, it already works and is portable to non-GNU systems which
> is a plus. Furthermore, it also works with other programs that also
> return 0,1,>1 depending on success,failure,error (e.g., 'cmp',
> 'diff', 'sort'), and it doesn't sound like much of a win to add
> unportable --pipe options to every such program.

I wasn't aware of those, but I'd say they are candidates as well! I
receive the result of the grep operation on stdout, so I don't want any
categorization via the exit code.

I'm also still not 100% sure on the idea, which is why I'm putting this
up for discussion. I think my main two arguments are

 - Shell scripting uses nonzero exit codes to signal errors by default.
   grep is an exception here (as are cmp, diff and sort as I understand
   you), and for a reason, but it doesn't provide an option to use
   default behaviour.
 - Also, just arguing in the context of grep, there is an option to
   "just tell me if there was a match, don't give me the results" and I
   want a complementary "just give me the results, don't tell me if
   there was a match".


> And it's not just commands like 'cmp' and 'grep'. The following
> causes Bash to exit on GNU/Linux:
> 
> set -eo pipefail
> cat /usr/share/dict/american-english | grep -l '^'
> 
> This is not because of anything 'grep' does, as 'grep' exits with
> status zero. It's because 'cat' exits with nonzero status. Surely we
> shouldn't add a --pipe option to 'cat' too.

It doesn't do that here, I wonder why you are seeing an error there?
Also, if it did, that would signal an actual error, which is behaviour
I'm completely fine with.


That said, I received feedback from another side (busybox) which is
strongly against a `-p` alias, because BSD grep already uses that one.


Thank you for your input, Paul, I'm enjoying this exchange!


Uli





reply via email to

[Prev in Thread] Current Thread [Next in Thread]