From: "Torsten Bögershausen" <tboegi@web.de>
To: "Junio C Hamano" <gitster@pobox.com>,
"Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] t9001: avoid not portable '\n' with sed
Date: Wed, 04 Jun 2014 20:42:35 +0200 [thread overview]
Message-ID: <538F689B.1020804@web.de> (raw)
In-Reply-To: <xmqqd2eov8ys.fsf@gitster.dls.corp.google.com>
On 2014-06-04 20.13, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Torsten Bögershausen <tboegi@web.de> writes:
>>
>>> t9001 used a '\n' in a sed expression to split one line into two lines.
>>> Some versions of sed simply ignore the '\' before the 'n', treating
>>> '\n' as 'n'.
>>>
>>> As the test already requires perl as a prerequisite, use perl instead of sed.
>>>
>>> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
>>> ---
>>
>> Hmph. I read this in pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
>>
>> The escape sequence '\n' shall match a <newline> embedded in the
>> pattern space.
>>
>> so it may be better to be a bit more explicit in the log message to
>> say whose implementation has this issue to warn people.
>>
>>> t/t9001-send-email.sh | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
>>> index 64d9434..2bf48d1 100755
>>> --- a/t/t9001-send-email.sh
>>> +++ b/t/t9001-send-email.sh
>>> @@ -1342,7 +1342,7 @@ test_cover_addresses () {
>>> git format-patch --cover-letter -2 -o outdir &&
>>> cover=`echo outdir/0000-*.patch` &&
>>> mv $cover cover-to-edit.patch &&
>>> - sed "s/^From:/$header: extra@address.com\nFrom:/" cover-to-edit.patch >"$cover" &&
>>> + "$PERL_PATH" -pe "s/^From:/$header: extra\@address.com\nFrom:/" cover-to-edit.patch | tr Q "$LF" >"$cover" &&
>>
>> We have a shell function "perl" in test-lib-function.sh these days
>> so that you do not have to write "$PERL_PATH" yourself in tests ;-)
>
> Also, piping output from perl to tr feels somewhat suboptimal. I do
> not see where in the test material we use "Q to LF", and we may want
> to remove that altogether, but without that removal, an updated
> patch may look like this.
>
> t/t9001-send-email.sh | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index 64d9434..9f06b8c 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -1342,7 +1342,10 @@ test_cover_addresses () {
> git format-patch --cover-letter -2 -o outdir &&
> cover=`echo outdir/0000-*.patch` &&
> mv $cover cover-to-edit.patch &&
> - sed "s/^From:/$header: extra@address.com\nFrom:/" cover-to-edit.patch >"$cover" &&
> + perl -pe "
> + s/^From:/$header: extra\@address.com\nFrom:/;
> + y/Q/\n/;
> + " cover-to-edit.patch >"$cover" &&
> git send-email \
> --force \
> --from="Example <nobody@example.com>" \
Good catch, the "tr" should had been removed.
My first version used
sed "s/^From:/$header: extra@address.comQFrom:/"
and the Q was replaced by tr with a literal LF.
So I think the 'Q' -> '\n' conversion should be removed completely :-)
The sed in question is /usr/bin/sed under Mac OS X.
Then we have the question: What exactly is the pattern space?
>In default operation, sed cyclically shall append a line of input, less its terminating <newline> >character, into the pattern space....
Isn't that the stuff from the input?
But that doesn't make too much sence to me, since "input lines" are terminated by \n.
So pattern space seems to mean output when they talk about the \n
Anyway, the \n (to insert a newline into the output) works under Linux, but not Mac OS.
next prev parent reply other threads:[~2014-06-04 18:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 8:20 [PATCH] t9001: avoid not portable '\n' with sed Torsten Bögershausen
2014-06-04 17:42 ` Junio C Hamano
2014-06-04 18:13 ` Junio C Hamano
2014-06-04 18:42 ` Torsten Bögershausen [this message]
2014-06-04 18:46 ` John Keeping
2014-06-04 19:01 ` Junio C Hamano
2014-06-04 19:16 ` Andreas Schwab
2014-06-04 18:47 ` David Kastrup
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=538F689B.1020804@web.de \
--to=tboegi@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).