[32675] in Perl-Users-Digest
Perl-Users Digest, Issue: 3951 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 20 21:09:23 2013
Date: Mon, 20 May 2013 18:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 20 May 2013 Volume: 11 Number: 3951
Today's topics:
Re: Efficiency of s///e? (Tim McDaniel)
Re: Efficiency of s///e? <ben@morrow.me.uk>
Re: Efficiency of s///e? <derykus@gmail.com>
Re: Efficiency of s///e? <whynot@pozharski.name>
Re: Efficiency of s///e? <ben@morrow.me.uk>
Re: Efficiency of s///e? <szr@sREzMOrVEoman.com>
Re: Efficiency of s///e? <ben@morrow.me.uk>
Re: Efficiency of s///e? <whynot@pozharski.name>
Re: Efficiency of s///e? <rweikusat@mssgmbh.com>
Re: Efficiency of s///e? <ben@morrow.me.uk>
Re: Efficiency of s///e? <whynot@pozharski.name>
Re: Efficiency of s///e? (Tim McDaniel)
I'd like to try Perl... <peterxpercival@hotmail.com>
Re: I'd like to try Perl... <rvtol+usenet@xs4all.nl>
Re: I'd like to try Perl... <marc.girod@gmail.com>
Re: I'd like to try Perl... <peterxpercival@hotmail.com>
Re: I'd like to try Perl... <ben@morrow.me.uk>
Re: Perl regex - How to make my greedy quantifier greed <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 17 May 2013 16:57:24 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Efficiency of s///e?
Message-Id: <kn5nhk$rku$1@reader1.panix.com>
In article <928h6a-c8i.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>A block like
>
> s{...}{
> # code
> }gex;
You don't need the "x" to allow arbitrary formatting on the right-hand
side, only for the left, right?
>isn't entirely different from an if: to some extent it's just a
>brace-delimited block like any other. However, given that it does
>actually have slightly strange parsing rules,
Oh, please don't leave it like that, you code-tease! Is it because
the terminator, "}" here, can screw it up?
s{...}{
$blort .= "}";
}
would screw up by terminating at the apparently "inner" "}"?
(perlop, Gory details of parsing quoted constructs) Or anything else?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 17 May 2013 20:35:30 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Efficiency of s///e?
Message-Id: <2ddi6a-o4o2.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <928h6a-c8i.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >A block like
> >
> > s{...}{
> > # code
> > }gex;
>
> You don't need the "x" to allow arbitrary formatting on the right-hand
> side, only for the left, right?
I think with /e that's right, yes. That hadn't occurred to me... (I just
checked and you can include comments in the RHS with /e, which is what I
thought might not have worked.)
> >isn't entirely different from an if: to some extent it's just a
> >brace-delimited block like any other. However, given that it does
> >actually have slightly strange parsing rules,
>
> Oh, please don't leave it like that, you code-tease! Is it because
> the terminator, "}" here, can screw it up?
> s{...}{
> $blort .= "}";
> }
>
> would screw up by terminating at the apparently "inner" "}"?
> (perlop, Gory details of parsing quoted constructs) Or anything else?
The handling of the closing terminator is what I was referring to. The
first unbalanced, unescaped } will close the s{}{}e, and \} will be
converted to } before the read-this-as-Perl parser sees it. Fortunately
there are relatively few real situations where this matters, though it's
easy to create artificial situations with bizarre results, like
s{...}{ { "foo" \} # } }e
It's also worth noting that \\ is *not* converted to \, even though \\}
prevents the backslash from escaping the }. As I said, slightly strange
rules...
Ben
------------------------------
Date: Fri, 17 May 2013 13:09:32 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Efficiency of s///e?
Message-Id: <kn62qd$q9a$1@speranza.aioe.org>
On 5/17/2013 9:57 AM, Tim McDaniel wrote:
> In article <928h6a-c8i.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
>> A block like
>>
>> s{...}{
>> # code
>> }gex;
>
> You don't need the "x" to allow arbitrary formatting on the right-hand
> side, only for the left, right?
Yes. I meant show comments on the left. See what I mean about vertigo...
>
>> isn't entirely different from an if: to some extent it's just a
>> brace-delimited block like any other. However, given that it does
>> actually have slightly strange parsing rules,
>
> Oh, please don't leave it like that, you code-tease! Is it because
> the terminator, "}" here, can screw it up?
> s{...}{
> $blort .= "}";
> }
>
> would screw up by terminating at the apparently "inner" "}"?
> (perlop, Gory details of parsing quoted constructs) Or anything else?
Yes, usually, you'd have to escape delimiters, "\}" or "\{"
Though, if you have a matching pair, you're ok:
{ $blort .= "{}"; }e
Yet, escaping one, but not both, there's a problem again:
( $blort .= "\{}"; }e; # verboten!
--
Charles DeRykus
------------------------------
Date: Sat, 18 May 2013 10:30:24 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Efficiency of s///e?
Message-Id: <slrnkpebgg.a6b.whynot@orphan.zombinet>
with <928h6a-c8i.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
>
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 5/16/2013 8:36 PM, Tim McDaniel wrote:
>> > There's a sub in our code base which has something like
>> >
>> > my $prevent_infinite_loop = 0;
>> > while ($prevent_infinite_loop++ < 1000 && $text =~ /(complicated)
>> (regular) (expression)/) {
>> > ... various calculations on $1, $2, $3, ... resulting in
>> $replacement;
>> > $text =~ s/(complicated) (regular) (expression)/$replacement/;
>> > # that's exactly the same regular expression as above
>> > }
>> >
>> > (though I think that, with the particular pattern, an infinite loop is
>> > impossible.) To add new features and for maintainability,
>> > I've developed
>> >
>> > $text =~ s{(simpler)}{
>> > my $found = $1;
>> > ... various calculations involving split on $found, unshift, ...
>> > $replacement;
>> > }eg;
>
> You can also use @+ and substr, as was discussed here a little while
> ago:
>
> while (... and $text =~ /.../) {
> my ($start, $length) = ($-[0], $+[0] - $-[0]);
>
> # calculate $replacement
>
> substr $text, $start, $length, $replacement;
> }
>
Care to explain why you replaced $prevent_infinite_loop with elipsis?
#!/usr/bin/perl
use strict;
use warnings;
my( $aa, $ab ) = qw/ aaaa bbbb /;
my $prevent_infinite_loop;
while( ++$prevent_infinite_loop < 1000 && $aa =~ /aa/ ) {
my( $start, $length ) = ( $-[0], $+[0] + $-[0] );
my $replacement = 'a';
substr $aa, $start, $length, $replacement;
print "aa: $aa\n";
}
$ab =~ s{bb}{ print "ab (before): $ab\n"; 'b' }ge;
print "ab (now): $ab\n";
__END__
{2809:6} [0:0]% p.x foo.tI7BTR.pl
p.x:1: no such file or directory: ./Build
aa: aaa
aa: aa
aa: a
ab (before): bbbb
ab (before): bbbb
ab (now): bb
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Sat, 18 May 2013 14:26:49 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Efficiency of s///e?
Message-Id: <p5ck6a-q17.ln1@anubis.morrow.me.uk>
Quoth Eric Pozharski <whynot@pozharski.name>:
> with <928h6a-c8i.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
> >
> > Quoth Charles DeRykus <derykus@gmail.com>:
> >> On 5/16/2013 8:36 PM, Tim McDaniel wrote:
> >> > There's a sub in our code base which has something like
> >> >
> >> > my $prevent_infinite_loop = 0;
> >> > while ($prevent_infinite_loop++ < 1000 && $text =~ /(complicated)
> >> (regular) (expression)/) {
[...]
> >
> > You can also use @+ and substr, as was discussed here a little while
> > ago:
> >
> > while (... and $text =~ /.../) {
[...]
>
> Care to explain why you replaced $prevent_infinite_loop with elipsis?
To avoid having to type '$prevent_infinite_loop++ < 1000'? No other
reason; the implication was intended to be 'this bit is the same as
before', just like the inside of the regex.
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my( $aa, $ab ) = qw/ aaaa bbbb /;
>
> my $prevent_infinite_loop;
> while( ++$prevent_infinite_loop < 1000 && $aa =~ /aa/ ) {
> my( $start, $length ) = ( $-[0], $+[0] + $-[0] );
> my $replacement = 'a';
> substr $aa, $start, $length, $replacement;
> print "aa: $aa\n";
> }
>
> $ab =~ s{bb}{ print "ab (before): $ab\n"; 'b' }ge;
> print "ab (now): $ab\n";
>
> __END__
>
> {2809:6} [0:0]% p.x foo.tI7BTR.pl
> p.x:1: no such file or directory: ./Build
> aa: aaa
> aa: aa
> aa: a
> ab (before): bbbb
> ab (before): bbbb
> ab (now): bb
I'm not sure what this is supposed to be demonstrating...
Ben
------------------------------
Date: Sat, 18 May 2013 15:51:11 -0700
From: szr <szr@sREzMOrVEoman.com>
Subject: Re: Efficiency of s///e?
Message-Id: <kn90l001v4u@news4.newsguy.com>
On 5/17/2013 12:35 PM, Ben Morrow wrote:
> The handling of the closing terminator is what I was referring to. The
> first unbalanced, unescaped } will close the s{}{}e, and \} will be
> converted to } before the read-this-as-Perl parser sees it. Fortunately
> there are relatively few real situations where this matters, though it's
> easy to create artificial situations with bizarre results, like
>
> s{...}{ { "foo" \} # } }e
>
> It's also worth noting that \\ is*not* converted to \, even though \\}
> prevents the backslash from escaping the }. As I said, slightly strange
> rules...
The same also seems to be true of eval( expr ), such as in:
eval qq{ { "foo" \} # } };
Remove the closing curly brace immediately after the # and you get a
Can't find string terminator "}" ...
error, not unlike what happens when the same is done in a substitution
like yours above.
Also, keep in mind, in the substitution, you can use other delimiters
besides { ... }, such as:
$s =~ s{ ... }< { "foo" } # } >e
In which case escaping that } that comes before the # actually cases an
error:
syntax error at line ..., near ""foo" \"
Although, the same is no completely true of qq<...>, as both
eval qq< { "foo" \} # } >;
and
eval qq< { "foo" } # } >;
yield no errors or warnings and return the string: foo
Not sure what exactly accounts for this difference though.
--
szr
------------------------------
Date: Sun, 19 May 2013 00:26:10 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Efficiency of s///e?
Message-Id: <i9fl6a-50i1.ln1@anubis.morrow.me.uk>
Quoth szr <szr@sREzMOrVEoman.com>:
> On 5/17/2013 12:35 PM, Ben Morrow wrote:
> > The handling of the closing terminator is what I was referring to. The
> > first unbalanced, unescaped } will close the s{}{}e, and \} will be
> > converted to } before the read-this-as-Perl parser sees it. Fortunately
> > there are relatively few real situations where this matters, though it's
> > easy to create artificial situations with bizarre results, like
> >
> > s{...}{ { "foo" \} # } }e
> >
> > It's also worth noting that \\ is*not* converted to \, even though \\}
> > prevents the backslash from escaping the }. As I said, slightly strange
> > rules...
>
> The same also seems to be true of eval( expr ), such as in:
>
> eval qq{ { "foo" \} # } };
>
> Remove the closing curly brace immediately after the # and you get a
>
> Can't find string terminator "}" ...
>
> error, not unlike what happens when the same is done in a substitution
> like yours above.
Yep, and for much the same reason: the RHS of a s/// is basically a
qq//-quoted string. The most important difference is that, unlike eval,
s///e compiles its RHS at compile time, which I think accounts for the
differences you point out below.
> Also, keep in mind, in the substitution, you can use other delimiters
> besides { ... }, such as:
>
> $s =~ s{ ... }< { "foo" } # } >e
You can, but it's usually a bad idea with /e. < and > in particular
often appear alone, so the chance of accidentally closing the s///e is
much higher. Also, code blocks in Perl are usually brace-delimited, so
it's clearer if that applies to s///e as well.
> In which case escaping that } that comes before the # actually cases an
> error:
>
> syntax error at line ..., near ""foo" \"
>
> Although, the same is no completely true of qq<...>, as both
>
> eval qq< { "foo" \} # } >;
>
> and
>
> eval qq< { "foo" } # } >;
>
> yield no errors or warnings and return the string: foo
>
> Not sure what exactly accounts for this difference though.
toke.c :). The Perl string-parsing rules are *terrifying*; there's one
place in toke.c where the code takes a weighted average of probabilities
to guess whether {...} in a regexp is a hash-subscript or a {1,2}
construction. If it weren't for the fact that it actually seems to do
what you expect almost all the time it would make me thoroughly nervous.
In this case, I think the difference is that s///e sees the string at
compile time, as it was written in the source, and just applies an extra
rule about unescaping escaped closing delimiters. eval sees the string
at runtime, after it's been parsed by the qq// parser, by which point
the backslash has already disappeared.
There are other differences because of this; for instance
perl -E'$_ = "f"; s/f/\\$x/e; say; say eval qq/\\\$x/'
In fact, the RHS of s///e is more like q// than qq//, except that even
q// converts \\ -> \ which s///e doesn't.
Ben
------------------------------
Date: Sun, 19 May 2013 13:38:36 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Efficiency of s///e?
Message-Id: <slrnkphatc.om4.whynot@orphan.zombinet>
with <p5ck6a-q17.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
*SKIP*
>> #!/usr/bin/perl
>>
>> use strict;
>> use warnings;
>>
>> my( $aa, $ab ) = qw/ aaaa bbbb /;
>>
>> my $prevent_infinite_loop;
>> while( ++$prevent_infinite_loop < 1000 && $aa =~ /aa/ ) {
>> my( $start, $length ) = ( $-[0], $+[0] + $-[0] );
>> my $replacement = 'a';
>> substr $aa, $start, $length, $replacement;
>> print "aa: $aa\n";
>> }
>>
>> $ab =~ s{bb}{ print "ab (before): $ab\n"; 'b' }ge;
>> print "ab (now): $ab\n";
>>
>> __END__
>>
>> {2809:6} [0:0]% p.x foo.tI7BTR.pl
>> p.x:1: no such file or directory: ./Build
>> aa: aaa
>> aa: aa
>> aa: a
>> ab (before): bbbb
>> ab (before): bbbb
>> ab (now): bb
>
> I'm not sure what this is supposed to be demonstrating...
I'm trying to show that
while( m// ) { code(); s/// }
differs from
s//code()/eg
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Sun, 19 May 2013 18:56:42 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Efficiency of s///e?
Message-Id: <87zjvqam5h.fsf@sapphire.mobileactivedefense.com>
Eric Pozharski <whynot@pozharski.name> writes:
> with <p5ck6a-q17.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
>>> #!/usr/bin/perl
>>>
>>> use strict;
>>> use warnings;
>>>
>>> my( $aa, $ab ) = qw/ aaaa bbbb /;
>>>
>>> my $prevent_infinite_loop;
>>> while( ++$prevent_infinite_loop < 1000 && $aa =~ /aa/ ) {
>>> my( $start, $length ) = ( $-[0], $+[0] + $-[0] );
>>> my $replacement = 'a';
>>> substr $aa, $start, $length, $replacement;
>>> print "aa: $aa\n";
>>> }
>>>
>>> $ab =~ s{bb}{ print "ab (before): $ab\n"; 'b' }ge;
>>> print "ab (now): $ab\n";
>>>
>>> __END__
>>>
>>> {2809:6} [0:0]% p.x foo.tI7BTR.pl
>>> p.x:1: no such file or directory: ./Build
>>> aa: aaa
>>> aa: aa
>>> aa: a
>>> ab (before): bbbb
>>> ab (before): bbbb
>>> ab (now): bb
>>
>> I'm not sure what this is supposed to be demonstrating...
>
> I'm trying to show that
>
> while( m// ) { code(); s/// }
>
> differs from
>
> s//code()/eg
In particular, s///g scans the text from left to right and replaces
matches it found in the original input string. The loop will rescan
the text upon each iteration, possibly performing replacements on the
results of earlier replacements.
------------------------------
Date: Sun, 19 May 2013 23:00:42 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Efficiency of s///e?
Message-Id: <alun6a-r572.ln1@anubis.morrow.me.uk>
Quoth Eric Pozharski <whynot@pozharski.name>:
> with <p5ck6a-q17.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
>
> > I'm not sure what this is supposed to be demonstrating...
>
> I'm trying to show that
>
> while( m// ) { code(); s/// }
>
> differs from
>
> s//code()/eg
OK. Then I'm not sure *why* you're demonstrating that, since I wasn't
questioning it.
Ben
------------------------------
Date: Mon, 20 May 2013 09:19:48 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Efficiency of s///e?
Message-Id: <slrnkpjg44.9j8.whynot@orphan.zombinet>
with <alun6a-r572.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
*SKIP*
> OK. Then I'm not sure *why* you're demonstrating that, since I wasn't
> questioning it.
Good. Now I have a better understanding of your way of thinking. It
won't make problems anymore.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Mon, 20 May 2013 15:58:39 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Efficiency of s///e?
Message-Id: <kndh7e$osm$1@reader1.panix.com>
In article <slrnkphatc.om4.whynot@orphan.zombinet>,
Eric Pozharski <whynot@pozharski.name> wrote:
>I'm trying to show that
>
> while( m// ) { code(); s/// }
>
>differs from
>
> s//code()/eg
Oh, rescanning! Yes, in general that should indeed be considered, and
thank you for mentioning it -- s///g doesn't rescan and so avoids any
infinite loop problems.
(If you're curious about my original problem that prompted this:
rescanning doesn't produce any different results for my case -- the
right-hand side of the s/// cannot produce text that would match
again. The pattern it's looking for is very roughly
[[ (word character or space) * | (word character or space) * ]]
and the replacement is one of the alternatives, which therefore
cannot have [ or ].)
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 20 May 2013 15:04:34 +0100
From: Peter Percival <peterxpercival@hotmail.com>
Subject: I'd like to try Perl...
Message-Id: <kndaie$j7q$1@news.albasani.net>
I'd like to try Perl on Win 7 and according to this:
http://www.perl.org/get.html, it's a choice between ActiveState,
Strawberry and DWIM. Any advice on choosing between them would be welcome.
------------------------------
Date: Mon, 20 May 2013 16:50:46 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: I'd like to try Perl...
Message-Id: <519a3846$0$15863$e4fe514c@news2.news.xs4all.nl>
On 20/05/2013 16:04, Peter Percival wrote:
> I'd like to try Perl on Win 7 and according to this:
> http://www.perl.org/get.html, it's a choice between ActiveState,
> Strawberry and DWIM. Any advice on choosing between them would be welcome.
Consider CitrusPerl as well, as it includes Wx + DBI.
http://www.citrusperl.com/
StrawberryPerl already provides 5.18.0.1.
CitrusPerl is at 5.16.3.
--
Ruud
------------------------------
Date: Mon, 20 May 2013 12:44:38 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: I'd like to try Perl...
Message-Id: <d9ac9117-18c9-4114-ad7a-612c23ba1dd5@dk8g2000vbb.googlegroups.com>
On May 20, 3:04=A0pm, Peter Percival <peterxperci...@hotmail.com> wrote:
> I'd like to try Perl on Win 7 and according to this:http://www.perl.org/g=
et.html, it's a choice between ActiveState,
> Strawberry and DWIM. =A0Any advice on choosing between them would be welc=
ome.
ActivePerl is compiled with a Microsoft compiler (the Visual C++
Express Edition is available for free), and Strawberry with a bundled
gcc.
This will impact the ease with which CPAN modules interfacing with
shared libraries will drop.
Note also the Cygwin option...
Marc
------------------------------
Date: Mon, 20 May 2013 21:02:59 +0100
From: Peter Percival <peterxpercival@hotmail.com>
Subject: Re: I'd like to try Perl...
Message-Id: <kndvhl$bjv$1@news.albasani.net>
Marc Girod wrote:
> On May 20, 3:04 pm, Peter Percival <peterxperci...@hotmail.com> wrote:
>> I'd like to try Perl on Win 7 and according to this:http://www.perl.org/get.html, it's a choice between ActiveState,
>> Strawberry and DWIM. Any advice on choosing between them would be welcome.
>
> ActivePerl is compiled with a Microsoft compiler (the Visual C++
> Express Edition is available for free
I didn't know that. Thank you for drawing my attention to it.
> ), and Strawberry with a bundled
> gcc.
> This will impact the ease with which CPAN modules interfacing with
> shared libraries will drop.
Maybe both then!
> Note also the Cygwin option...
>
> Marc
>
------------------------------
Date: Tue, 21 May 2013 01:23:58 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: I'd like to try Perl...
Message-Id: <udrq6a-ebu2.ln1@anubis.morrow.me.uk>
Quoth Peter Percival <peterxpercival@hotmail.com>:
> I'd like to try Perl on Win 7 and according to this:
> http://www.perl.org/get.html, it's a choice between ActiveState,
> Strawberry and DWIM. Any advice on choosing between them would be welcome.
Strawberry is most like perl on other systems: it comes with a copy of
the compiler it was compiled with, so CPAN.pm and the other standard
Perl CPAN interfaces work properly. Strawberry is actually an offshoot
of the Vanilla Perl project (see what they did there?) which was
intended to create an easy-to-install system for building perl from
source, just like on Unix systems. All Strawberry adds to that is
preinstalled versions of a number of libraries and their corresponding
Perl modules which are known to be difficult to install on Win32.
ActivePerl, on the other hand, is much more more of a Windows system.
The standard way to install modules is through ActiveState's PPM system,
which installs prebuilt binaries from special repostitories. This has
advantages and disadvantages: the modules are prebuilt, which saves time
and possibly trouble building them; they include (where necessary)
copies of any C libraries they require, which can be a problem on Win32;
and the PPM interface is considerably more sophisticated than any of the
standard Perl CPAN interfaces, with facilities for uninstalling modules
and easily getting a list of which modules are out of date. On the other
hand, you only get the modules which have been built for PPM, which is
usually a great deal less than all of CPAN.
DWIM I had not come across before; it looks to me like an implementation
of an idea the Strawberry people were talking about a while ago, for a
'Chocolate Perl' which includes not just those modules known to be
difficult to install but some reasonable stab at 'all the modules you
are likely to want'. (The problem with this idea is that while nearly
everyone agreed this was a good plan, noone could agree which modules
should go on the list...) If you were going to install Strawberry but
would rather install a bit more now to avoid faffing with CPAN later,
this sounds like a good choice.
If I needed Perl on Windows I would use Strawberry, but then I already
know how to use Perl and want it to look the way it does on Unix. For a
beginner I might recommend DWIM; the choice of modules included will
certainly point you in the right direction, and if you don't already
have a favourite editor Padre is probably a decent place to start. (I'm
somewhat biased against ActiveState, for reasons that probably don't
apply any more.)
Ben
------------------------------
Date: Fri, 17 May 2013 10:07:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl regex - How to make my greedy quantifier greedier?
Message-Id: <4k8h6a-c8i.ln1@anubis.morrow.me.uk>
Quoth Christian Winter <thepoet_nospam@arcor.de>:
> Am 17.05.2013 05:46, schrieb cibalo:
> > What I am looking for is the result similar to:
> > $ find testing -type f -name "[a-z]*\.txt"
> > testing/dir.a/dir_b/dir-c/this-is-testing4_org.txt
> > testing/dir.a/dir_b/dir-c/this_is_testing3_org.txt
> > I know it is more easier to find the result this way.
>
> > Now I try with perl regex as:
> > $ ls testing/dir.a/dir_b/dir-c/* | perl -ne '/^(.*\/)([a-z].*)$/;
> > print $1, " - ", $2, "\n";'
> > testing/dir.a/dir_b/ - dir-c/This_is_testing1_org.txt
> > testing/dir.a/dir_b/ - dir-c/This-is-testing2_org.txt
> > testing/dir.a/dir_b/dir-c/ - this_is_testing3_org.txt
> > testing/dir.a/dir_b/dir-c/ - this-is-testing4_org.txt
> > Actually, I want my leftmost greedy quantifier, (.*\/), to be so
> > greedier that it can prevent the first two output items from listing.
It's important to realise that (non-)greediness can never prevent a
pattern from matching, it only changes which parts of the pattern match
which parts of the text. As Damien pointed out, possessiveness, that is
(?>) or .*+, can stop a pattern from matching, but in this case the .*+
in (.*+\/) would run all the way to the end of the string and refuse to
give any up, so you still wouldn't get what you want.
> Two approaches instantly come to my mind:
>
> 1. Modifying the pattern for the filename so it looses
> its greediness, which unfortunately isn't solved by
> adding the non-greedy modifier. A simple solution is
> looking for anything but a slash:
> /^ (.*\/) ([^\/]+) $/x;
That's not the same. What the OP hasn't realised is that '*' in a glob
is not equivalent to .*, it's equivalent to [^/]*. So a simple
translation of the original find pattern would be m!/[a-z][^/]*\.txt$!
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3951
***************************************
