Re: [PATCH] t3920: don't ignore errors of more than one command with `|| true`
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 23, 2022, 00:55 UTC
- Message-ID
- <xmqq1qpupk0k.fsf@gitster.g>
- In-Reply-To
- <221123.86ilj6a8ux.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 23 quoted lines
> 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".