From: Eric Sunshine <sunshine@sunshineco.com>
To: Jeff King <peff@peff.net>
Cc: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>,
"Célestin Matte" <celestin.matte@ensimag.fr>,
"Git List" <git@vger.kernel.org>,
benoit.person@ensimag.fr
Subject: Re: [PATCH] git-remote-mediawiki: Fix a bug in a regexp
Date: Sun, 9 Jun 2013 01:21:43 -0400 [thread overview]
Message-ID: <CAPig+cSCLsMQ3Xg9UKury41G0vHddnL1PVKBJL_N2amA9e0eyQ@mail.gmail.com> (raw)
In-Reply-To: <20130609025708.GB30393@sigill.intra.peff.net>
On Sat, Jun 8, 2013 at 10:57 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Jun 08, 2013 at 08:38:56PM +0200, Matthieu Moy wrote:
>
>> Célestin Matte <celestin.matte@ensimag.fr> writes:
>>
>> > In Perl, '\n' is not a newline, but instead a literal backslash followed by an
>> > "n". As the output of "rev-list --first-parent" is line-oriented, what we want
>> > here is a newline.
>>
>> This is right, but the code actually worked the way it was. I'm not
>> sure, but my understanding is that '\n' is the string "backslash
>> followed by n", but interpreted as a regexp, it is a newline.
>
> Yes, the relevant doc (from "perldoc -f split") is:
>
> The pattern "/PATTERN/" may be replaced with an expression to specify
> patterns that vary at runtime. (To do runtime compilation only once,
> use "/$variable/o".)
>
> So it is treating "\n" as an expression and compiling the regex each
> time through ...
I read this as saying only that static /PATTERN/ can also be a
composed /$PATTERN/. It does not indicate how string 'PATTERN' is
treated, nor does any other part of "perldoc -f split" make special
mention of string 'PATTERN'. In fact, the only explanation I found
regarding string 'PATTERN' is in my Camel book (3rd edition, page 796)
in a parenthesized comment:
(... if you supply a string instead of a regular expression, it'll be
interpreted as a regular expression anyway.)
>> The new code looks better than the old one, but the log message may be
>> improved.
>
> Agreed. I think the best explanation is something like:
>
> Perl's split function takes a regex pattern argument. You can also
> feed it an expression, which is then compiled into a regex at runtime.
> It therefore works to pass your pattern via single quotes, but it is
> much less obvious to a reader that the argument is meant to be a
> regex, not a static string. Using the traditional slash-delimiters
> makes this easier to read.
Sounds good to me.
next prev parent reply other threads:[~2013-06-09 5:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-08 13:35 [PATCH] git-remote-mediawiki: Fix a bug in a regexp Célestin Matte
2013-06-08 18:38 ` Matthieu Moy
2013-06-08 20:08 ` Célestin Matte
2013-06-09 2:57 ` Jeff King
2013-06-09 5:21 ` Eric Sunshine [this message]
2013-06-09 5:11 ` 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=CAPig+cSCLsMQ3Xg9UKury41G0vHddnL1PVKBJL_N2amA9e0eyQ@mail.gmail.com \
--to=sunshine@sunshineco.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=benoit.person@ensimag.fr \
--cc=celestin.matte@ensimag.fr \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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).