From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Johannes Sixt" <j6t@kdbg.org>,
"Philippe Blain" <levraiphilippeblain@gmail.com>,
"René Scharfe" <l.s.r@web.de>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH] t3920: don't ignore errors of more than one command with `|| true`
Date: Wed, 23 Nov 2022 09:55:07 +0900 [thread overview]
Message-ID: <xmqq1qpupk0k.fsf@gitster.g> (raw)
In-Reply-To: <221123.86ilj6a8ux.gmgdl@evledraar.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Tue, 22 Nov 2022 23:57:20 +0100")
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> We have that "sed -n -e" in somewhat wide use:
>
> $ git grep 'sed (-n -e|-ne).*/p.*&&' | wc -l
> 54
>
> The only existing occurance of this "grep but ignore the exit code" I
> could find was:
>
> t/t9001-send-email.sh: { grep '^X-Mailer:' out || :; } >mailer &&
>
> For which we can also:
>
> - { grep '^X-Mailer:' out || :; } >mailer &&
> + sed -ne '/^X-Mailer:/p' <out >mailer &&
>
> And which I'd think would be great to have in a re-roll, i.e. "here's
> these two cases where a grep-but-dont-care-about-the-exit-code could be
> replaced by sed -ne".
>
> But if re-testing this is tedious etc. I don't mind if it goes in as-is,
> but then I'd think we could safely emulate the t9001-send-email.sh
> pattern of using ":" instead of "true"; we don't need to invoke another
> process just to ignore the exit code.
Let's leave all of the above (mostly good ideas) for "after the dust
settles" clean-up.
If sed is much slower than grep (for such a small string use case,
start-up cost of a process would dwarf everybody else), "grep || :"
might be justifiable, but other than that I do not think of a good
reason why we might favor "grep || :" offhand over "sed -ne //p".
next prev parent reply other threads:[~2022-11-23 0:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-21 17:58 [PATCH] t3920: don't ignore errors of more than one command with `|| true` Johannes Sixt
2022-11-21 22:56 ` René Scharfe
2022-11-22 0:53 ` Junio C Hamano
2022-11-22 18:28 ` Philippe Blain
2022-11-22 22:24 ` Ævar Arnfjörð Bjarmason
2022-11-22 22:37 ` Johannes Sixt
2022-11-22 22:57 ` Ævar Arnfjörð Bjarmason
2022-11-23 0:55 ` Junio C Hamano [this message]
2022-12-02 16:51 ` [PATCH 2/1] t3920: support CR-eating grep René Scharfe
2022-12-02 23:14 ` Philippe Blain
2022-12-03 7:09 ` René Scharfe
2022-12-02 23:32 ` Eric Sunshine
2022-12-03 7:12 ` René Scharfe
2022-12-05 1:08 ` Junio C Hamano
2022-12-05 8:28 ` René Scharfe
2022-12-05 9:32 ` Junio C Hamano
2022-12-05 10:43 ` René Scharfe
2022-12-02 16:51 ` [PATCH 3/1] t3920: simplify redirection of loop output René Scharfe
2022-12-02 16:51 ` [PATCH 4/1] t3920: replace two cats with a tee René Scharfe
2022-12-03 5:09 ` Eric Sunshine
2022-12-03 8:43 ` René Scharfe
2022-12-03 12:53 ` Ævar Arnfjörð Bjarmason
2022-12-03 17:22 ` René Scharfe
2022-12-04 9:34 ` Ævar Arnfjörð Bjarmason
2022-12-04 16:39 ` Eric Sunshine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1qpupk0k.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=l.s.r@web.de \
--cc=levraiphilippeblain@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.