Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
>> may be easier to read and more portable (as some implementation of
>> sed is picky about semicolon concatenated multiple commands).
>
> For what it's worth, Git test scripts already contain a fair number of
> uses of semicolon-separated `sed` commands, and we haven't heard of
> any problems with them; not even from the very old and quite picky
> Solaris `sed` (or was it the ancient SunOS `sed`?).
I think it was of BSD lineage, but I phrased it poorly.
> sed -n '/ version /{p;q}'
This pattern did cause issues in the past. I was hoping that we can
avoid it by training our developers to avoid concatenation with
semicolons in general, but {grouped} commands cannot be fed without
properly using semicolons anyway, so it would not help to just
generally avoid use of semicolons.
On the other hand, the suggestion that was given in the message ...
>> > + sed -n "/^author /s/\([^>]*>\).*/\1/p; /^committer /s/\([^>]*>\).*/\1/p" log >actual &&
>>
>> Perhaps just a matter of taste, but
>>
>> sed -n -e "/^author /s/>.*/>/p" -e "/^committer /s/>.*/>/p"
... is much shorter, simpler and easier to understand. With the
added benefit that you can even line-wrap sensibly
sed -n -e "/^author /s/>.*/>/p" \
-e "/^committer /s/>.*/>/p"
there really isn't a good reason not to adopt the style, compared to
the way the patch was originally written.
