On Thu, Feb 17, 2022 at 3:27 PM Ulrich Eckhardt
wrote:
> >
> > Why do we need to implement a workaround in grep while you can
> > do this in shell to ignore the exit code of grep?
> >
> > { grep issue
> `grep -p ...` rather replaces `grep ... || test $? = 1`. The advantage
> is that it is
On Thu, Feb 17, 2022 at 12:50 PM Michael Conrad wrote:
>
> On 2/16/22 19:32, Kang-Che Sung wrote:
> >
> >> Now, for an example where it makes a difference. Consider a Bash script
> >> like this:
> >>
> >># enable automatic error handling
> >>set -eo pipefail
> >># check for string
On Thu, 17 Feb 2022 08:32:06 +0800
Kang-Che Sung wrote:
> On Thu, Feb 17, 2022 at 8:01 AM Ulrich Eckhardt
> wrote:
> > Now, for an example where it makes a difference. Consider a Bash
> > script like this:
> >
> > # enable automatic error handling
> > set -eo pipefail
> > # check for
On 2/16/22 19:32, Kang-Che Sung wrote:
Now, for an example where it makes a difference. Consider a Bash script
like this:
# enable automatic error handling
set -eo pipefail
# check for string "issues" in a logfile
cat logfile | grep issue | sort --unique
If there are no issues in
On Thu, Feb 17, 2022 at 8:01 AM Ulrich Eckhardt
wrote:
>
> I've implemented a `-p` flag for grep, which disables a behaviour that
> the exit status is used (abused?) to signal whether any match
> occurred.
The behaviour is POSIX.
> Now, for an example where it makes a difference. Consider a
Greetings!
I've implemented a `-p` flag for grep, which disables a behaviour that
the exit status is used (abused?) to signal whether any match
occurred. In many cases, you won't notice this. Also, in many cases,
shell scripts don't check for errors.
Now, for an example where it makes a
