Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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".
