[32451] in Perl-Users-Digest
Perl-Users Digest, Issue: 3718 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 18 14:09:40 2012
Date: Mon, 18 Jun 2012 11:09:07 -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, 18 Jun 2012 Volume: 11 Number: 3718
Today's topics:
Re: an effective script for grabbing and putting images <cal@example.invalid>
Calculating a negated character class <klaus03@gmail.com>
Re: Calculating a negated character class <ben@morrow.me.uk>
Re: Calculating a negated character class <klaus03@gmail.com>
Re: Calculating a negated character class <ben@morrow.me.uk>
Re: Calculating a negated character class <klaus03@gmail.com>
Re: new topic: I call length($<string>) and get number <rweikusat@mssgmbh.com>
Regular expression (WAS: an effective script for grabbi <jurgenex@hotmail.com>
Re: Regular expression (WAS: an effective script for gr <cal@example.invalid>
Re: Regular Expression <jurgenex@hotmail.com>
Re: Regular Expression <jurgenex@hotmail.com>
Re: Regular Expression <cal@example.invalid>
Re: Regular Expression <hjp-usenet2@hjp.at>
Re: Regular expression <jurgenex@hotmail.com>
Re: Regular Expression <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 17 Jun 2012 22:11:00 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: an effective script for grabbing and putting images from or to a website
Message-Id: <NfadnWVXQdjIN0PSnZ2dnUVZ_gidnZ2d@supernews.com>
On 06/17/2012 09:11 AM, Rainer Weikusat wrote:
> Ben Morrow<ben@morrow.me.uk> writes:
>> Quoth Rainer Weikusat<rweikusat@mssgmbh.com>:
>>> Ben Morrow<ben@morrow.me.uk> writes:
>>>> Quoth Rainer Weikusat<rweikusat@mssgmbh.com>:
>>>>> Ben Morrow<ben@morrow.me.uk> writes:
>>>>>>
>>>>>> ...and, you *also* need to check the match succeeded before you look at
>>>>>> $1:
>>>>>>
>>>>>> $name =~ m/.*\.(\w+)/ or die "'$name' has no extension";
>>>>>>
>>>>>> otherwise you run the risk of picking up $1 from some entirely other
>>>>>> pattern match. The $N variables are slightly strangely scoped, so this
>>>>>> is a little less likely than it might be, but it can and does happen and
>>>>>> causes *very* strange bugs when it does.
>> <snip>
>>>
>>> You didn't write anything regarding how the $n actually behave, just
>>> asserted they would be 'strangely scoped' and that this could case
>>> 'very strange bugs' in rarely occurring situations. That's about as
>>> sacry as it can get and nothing except scary.
>>
>> You appear to be extremely easily scared. BOO!
>
> Writing about 'strange scoping' which may cause or prevent 'very
> strange bugs' makes the matter appear by far more serious and arcane
> than it actually is. That's why I referred to it as
> 'scaremongering'. I didn't write that my assessment of the situation
> would be similar to your assesment and especially not that it was
> based on your text.
>
> [...]
>
>>>>> Practically, this means the simple way to use $1 etc correctly is to
>>>>> avoid using them except if the match supposed to set them was
>>>>> successful,
>>>>
>>>> ...as I said...
>>>
>>> You didn't. You wrote that it would be necessary to 'check the
>>> success of the match', suggested to use die for tha,t
>>
>> No, I suggested to use 'or' for that. The 'die' was the means of
>> diverting control away from the use of $1 if the match failed; I was
>> careful to mention that in this situation it may not be the most
>> appropriate way of doing so.
>
> This is a completely pointless attempt at confusing the issue by
> playing with words and absuing semantic ambiguities inherent in the
> way humans use language. It, however, enables me to ask a rethoric
> question:
>
> Assuming that
>
> $name =~ /deepfried (whole) elephant roll/ or die('Salatschrecke!')
>
> is 'sensible language use', according to your opinion, how come that
> the almost identical
>
> $name =~ /deepfried (whole) elephant roll/ and $quantity = $1;
>
> is 'crude and ugly'?
>
>>> and that - subject to the nameless but surely grave dangers - this
>>> featureshouldn't be used at all.
>>
>> The dangers were named
>
> Indeed. Their names were 'strange scopes' and 'very strange bugs'.
> But I'm tired of this weasel-wording exercise.
>
> [...]
>
>> <snip vaguely offensive nonsense>
>
> You could have snipped the 'vaguely offensive nonsense' from your
> original text and in this case, you wouldn't have provoked a reply which
> pointed out that you're condemning something without any reasons given
> because it was different from what you're accustomed to.
>
> In this case, I was actually thinking of something like
>
> test -n "$parameter"&& {
> # do something with it
> .
> .
> .
> }
>
> a construction I often use in shell scripts. Short-circuiting boolean
> operators can be used for flow control and often, this results in more
> concise code. The example above isn't anyhow enhanced by using
>
> if test -n "$paramerer";
> then
> .
> .
> .
> fi
>
> instead. That just makes it more verbose. And the closest analog in
> Perl for that is something like
>
> /.\.(\w+)$/&& do {
> .
> .
> .
> };
>
> You're free to dislike the style. I also dislike (quite a few) things
> about your coding style, I just usually refrain from posting this even
> despite I have more reasons for my opinion than "this is ugly":
> Different people do different things in different ways and
> BTNTWHIWHDI! (But that's not the way how I would have done it) is - at
> best - a very weak metric for 'code'.
Na Rainer,
Um deinen vorsicht nach meiner sache habe ich zu danken. Ben can make
fun as you help me understand--let's laugh it off: something that might
just save my butt someday, so I'm glad to see your comment. As it was,
I didn't have to use $1 syntax, ....
... but I still don't understand why deleted material is not also
returned in this idiom:
my ($ext) = $name =~ /([^.]*)$/;
Gruss aus Amiland,
--
Cal
------------------------------
Date: Mon, 18 Jun 2012 05:29:11 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Calculating a negated character class
Message-Id: <fadee83f-599e-4f9d-bf90-f4af4268d9fb@eh4g2000vbb.googlegroups.com>
Hello everybody,
I am trying to do a simple task: creating a regular expression with
qr{...}xms containing a simple character class. Then I can obviously
create the negated character class by putting a caret symbol at the
beginning inside the [...].
So far so good.
However, when I try (naively) to calculate the negated class from the
original character class, I get a compile time error:
Invalid [] range "x-i" in regex;
marked by <-- HERE in m/[^(?msx-i <-- HERE :[abc123])]/
at C:\test_regexp.pl line 6.
Here is my program
=========
use 5.012;
use warnings;
my $regexp_positive = qr{[abc123]}xms;
my $regexp_negated = qr{[^abc123]}xms;
my $calculated_negated = qr{[^$regexp_positive]}xms;
say "regexp_positive = $regexp_positive";
say "regexp_negated = $regexp_negated";
say "calculated_negated = $calculated_negated";
========
I understand that putting "(?msx-i" into a character class is not the
way forward, but how do I calculate the negated character class ?
Thanks in advance for your response.
-- Klaus
------------------------------
Date: Mon, 18 Jun 2012 13:50:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Calculating a negated character class
Message-Id: <tok3b9-a7p1.ln1@anubis.morrow.me.uk>
Quoth Klaus <klaus03@gmail.com>:
> Hello everybody,
>
> I am trying to do a simple task: creating a regular expression with
> qr{...}xms containing a simple character class. Then I can obviously
> create the negated character class by putting a caret symbol at the
> beginning inside the [...].
No, you can't. As you found out, you can't (usefully) interpolate a qr//
inside a character class.
> However, when I try (naively) to calculate the negated class from the
> original character class, I get a compile time error:
>
> Invalid [] range "x-i" in regex;
> marked by <-- HERE in m/[^(?msx-i <-- HERE :[abc123])]/
> at C:\test_regexp.pl line 6.
>
> Here is my program
> =========
> use 5.012;
> use warnings;
>
> my $regexp_positive = qr{[abc123]}xms;
> my $regexp_negated = qr{[^abc123]}xms;
> my $calculated_negated = qr{[^$regexp_positive]}xms;
This would not have worked in any case. You would have ended up with the
pattern
/[^[abc123]]/xms
which is not what you wanted.
> say "regexp_positive = $regexp_positive";
> say "regexp_negated = $regexp_negated";
> say "calculated_negated = $calculated_negated";
> ========
>
> I understand that putting "(?msx-i" into a character class is not the
> way forward, but how do I calculate the negated character class ?
my $cclass = "abc123";
my $regexp_positive = qr/[$cclass]/xms;
my $regexp_negated = qr/[^$cclass]/xms;
Ben
------------------------------
Date: Mon, 18 Jun 2012 06:33:47 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: Calculating a negated character class
Message-Id: <d04326f4-eddf-4bdb-952c-d6cdd34217ac@v9g2000vbc.googlegroups.com>
On 18 juin, 14:50, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Klaus <klau...@gmail.com>:
> > I understand that putting "(?msx-i" into a character class is not the
> > way forward, but how do I calculate the negated character class ?
>
> =A0 =A0 my $cclass =A0 =A0 =A0 =A0 =A0=3D "abc123";
> =A0 =A0 my $regexp_positive =3D qr/[$cclass]/xms;
> =A0 =A0 my $regexp_negated =A0=3D qr/[^$cclass]/xms;
Thanks for your reply. I can see clearer now.
So the way forward is isolating the class from the regexp construct.
Here is an updated version of my original program and it works!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
use 5.012;
use warnings;
my $regexp1_orig =3D qr{[abc123]}xms;
my $regexp2_orig =3D qr{[^def456]}xms;
say "regexp1_orig =3D $regexp1_orig";
say "regexp2_orig =3D $regexp2_orig";
my $regexp1_negated =3D negated($regexp1_orig);
my $regexp2_negated =3D negated($regexp2_orig);
say "regexp1_negated =3D $regexp1_negated";
say "regexp2_negated =3D $regexp2_negated";
sub negated {
my ($caret, $class) =3D $_[0] =3D~ m{\A \(\? [\w\-]* : \[ (\^?) (.*?)
\]\) \z}xms
or die "Can't parse regexp: $_[0]";
my $neg_caret =3D $caret eq '^' ? '' : '^';
my $neg_regexp =3D qr{[$neg_caret$class]}xms;
return $neg_regexp;
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The output is:
regexp1_orig =3D (?msx-i:[abc123])
regexp2_orig =3D (?msx-i:[^def456])
regexp1_negated =3D (?msx-i:[^abc123])
regexp2_negated =3D (?msx-i:[def456])
------------------------------
Date: Mon, 18 Jun 2012 17:31:39 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Calculating a negated character class
Message-Id: <bo14b9-o0p.ln1@anubis.morrow.me.uk>
Quoth Klaus <klaus03@gmail.com>:
> use 5.012;
> use warnings;
>
> my $regexp1_orig = qr{[abc123]}xms;
> my $regexp2_orig = qr{[^def456]}xms;
>
> say "regexp1_orig = $regexp1_orig";
> say "regexp2_orig = $regexp2_orig";
>
> my $regexp1_negated = negated($regexp1_orig);
> my $regexp2_negated = negated($regexp2_orig);
>
> say "regexp1_negated = $regexp1_negated";
> say "regexp2_negated = $regexp2_negated";
>
> sub negated {
> my ($caret, $class) = $_[0] =~ m{\A \(\? [\w\-]* : \[ (\^?) (.*?)
> \]\) \z}xms
In 5.14 the stringification syntax for qrs has changed. It now looks
like
(?^umsx:[abc123])
This was done to allow for future extensions to the set of /x flags. You
can either adjust your code to take account of this, or, better, use the
regexp_pattern function exported by the re module:
use re qw/regexp_pattern/;
my ($pattern, $flags) = regexp_pattern $_[0];
my ($caret, $class) = $pattern =~ /\A \[ (\^?) (.*?) \] \z/xms
or die ...;
Ben
------------------------------
Date: Mon, 18 Jun 2012 09:55:13 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: Calculating a negated character class
Message-Id: <b85440fa-f159-4349-acec-44373c8338ed@d6g2000vbe.googlegroups.com>
On 18 juin, 18:31, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Klaus <klau...@gmail.com>:
> > sub negated {
> > =A0 =A0 my ($caret, $class) =3D $_[0] =3D~ m{\A \(\? [\w\-]* : \[ (\^?)=
(.*?)
> > \]\) \z}xms
>
> In 5.14 the stringification syntax for qrs has changed. It now looks
> like
>
> =A0 =A0 (?^umsx:[abc123])
>
> This was done to allow for future extensions to the set of /x flags. You
> can either adjust your code to take account of this, or, better, use the
> regexp_pattern function exported by the re module:
>
> =A0 =A0 use re qw/regexp_pattern/;
>
> =A0 =A0 my ($pattern, $flags) =3D regexp_pattern $_[0];
> =A0 =A0 my ($caret, $class) =3D $pattern =3D~ /\A \[ (\^?) (.*?) \] \z/xm=
s
> =A0 =A0 =A0 =A0 or die ...;
Thank you very much for this information, I wasn't aware that the
stringification syntax differs between different versions perl.
I will use re qw/regexp_pattern/ as follows:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
use 5.012;
use warnings;
use re qw/regexp_pattern/;
my $regexp1_orig =3D qr{[abc123]}xms;
my $regexp2_orig =3D qr{[^def456]}xms;
say "regexp1_orig =3D $regexp1_orig";
say "regexp2_orig =3D $regexp2_orig";
my $regexp1_negated =3D negated($regexp1_orig);
my $regexp2_negated =3D negated($regexp2_orig);
say "regexp1_negated =3D $regexp1_negated";
say "regexp2_negated =3D $regexp2_negated";
sub negated {
my ($pattern, $flags) =3D regexp_pattern($_[0]);
my ($caret, $class) =3D
$pattern =3D~ m{\A \[ (\^?) (.*?) \] \z}xms
or die "Can't parse regexp: $_[0]";
my $neg_caret =3D $caret eq '^' ? '' : '^';
my $neg_regexp =3D qr{[$neg_caret$class]}xms;
return $neg_regexp;
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------------------------------
Date: Mon, 18 Jun 2012 15:18:01 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: new topic: I call length($<string>) and get number of lines - code frag below - on MAC OS X 10.7
Message-Id: <87ipeopuue.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>Code is not documentation.
>
> A source file
> - must express to the compiler the instructions to be followed
> - also ideally ought to communicate to a human reader, expressing the
> purpose and function of the overall file and of the various parts
>
> I believe that most code, just by being code, communicates its purpose
> to humans, at least at the lowest tactical levels and often even
> higher.
People believe in all kinds of strange stuff. If you wrote the code,
chances are that seeing it reminds you of its purpose. But that's
obviously not going to happen for anyone else and in this case, the
(source) code communicates what the code is doing but not why it is
doing this.
[...]
> The immediate case was someone writing a line that localized $/ and
> also expressed that they wanted it to be undefined. I'm not the one
> who expressed the notion that the undefined value is important to
> emphasize. Maybe you think that
> local $/;
> expresses the concept well enough.
local $/;
is an operation whose semantics are documented: It creates a new
lexical binding for $/ (meaning, one which exists until the (dynamic)
end of the enclosing block) and - as with all Perl variables which
aren't initialized - its initial value is the so-called 'undefined
value'.
> But I've hit enough problems of looking at a block of code and
> trying to figure out what the values are supposed to be at the end,
> and enough cases of assignments being forgotten, that I prefer to be
> explicit.
And I have encountered enough cases were people managed to outsmart
themselves in their own code and made 'trivial oversight' errors
because of that that I'm completely convinced that the overriding
concern when writing code ought to be: Keep it simple. Every
expression in the code is one which somebody who sees it for the first
time has to read and understand, there's always a possibility for
errors here and the more expressions there are, that is, the more
complicated the code is, the greater the chance of such a
misunderstanding becomes. And this implies that one should never, ever
write any code which doesn't have a well-defined technical purpose
someone who doesn't share a brain with the author can understand: Any
such occurence make the code more complicated, by virtue of adding
expressions to it, but since there's nothing tangible in return, this
is a completely useless complication.
Apart from that none of
local $/;
local $/ = undef;
local $/ = undef;
$/ = undef;
$/ = undef;
$/ = undef;
are anyhow more 'explicit' than any of the others. Pointles
repetitions do not serve to make a text clearer.
------------------------------
Date: Sun, 17 Jun 2012 21:35:51 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Regular expression (WAS: an effective script for grabbing and putting images from or to a website)
Message-Id: <inbtt7h5u8gmkmua3frnk133of5tav5h7l@4ax.com>
Cal Dershowitz <cal@example.invalid> wrote:
>... but I still don't understand why deleted material is not also
>returned in this idiom:
>
> my ($ext) = $name =~ /([^.]*)$/;
But there is no "deleted material" to begin with.
A regular expression matches text. What text does this one match? From
the end of the string forward anything that is not a dot. And that match
is captured by the paranthesis and thus copied to $ext.
There is nothing deleted at all. Just print $name and you will notice
that it didn't change one bit.
jue
------------------------------
Date: Sun, 17 Jun 2012 22:46:20 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: Regular expression (WAS: an effective script for grabbing and putting images from or to a website)
Message-Id: <N8mdnYNZItsGL0PSnZ2dnUVZ_qednZ2d@supernews.com>
On 06/17/2012 10:35 PM, Jürgen Exner wrote:
> Cal Dershowitz<cal@example.invalid> wrote:
>
>> ... but I still don't understand why deleted material is not also
>> returned in this idiom:
>>
>> my ($ext) = $name =~ /([^.]*)$/;
>
> But there is no "deleted material" to begin with.
>
> A regular expression matches text. What text does this one match? From
> the end of the string forward anything that is not a dot. And that match
> is captured by the [parenthesis] and thus copied to $ext.
>
> There is nothing deleted at all. Just print $name and you will notice
> that it didn't change one bit.
>
> jue
I see some of the logic now. Vielendank, ^[(^jue...
Do I understand correctly that this is a "greedy" comparison?
--
cal
------------------------------
Date: Sun, 17 Jun 2012 21:41:18 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Regular Expression
Message-Id: <s3ctt7h9q8cp0sia22psfr6b5m3l71h821@4ax.com>
Cal Dershowitz <cal@example.invalid> wrote:
>On 06/16/2012 10:26 PM, Jürgen Exner wrote:
>> Cal Dershowitz<cal@example.invalid> wrote:
>>> my ($ext) = $name =~ /([^.]*)$/;
>
>That one was super hard, with the carat not meaning what it usually does
Actually coming to think of it, no. Or rather sort of.
The special meaning you seem to be thinking of as anchor at the
beginning of the string happens only if the carat is the very first
character in the RE. Otherwise it is a normal character with no special
meaning except as first character in a character class (I hope I got
that right from memory).
>and the . as well. Good reading here:
Most characters loose their special meaning in a character class
jue
------------------------------
Date: Sun, 17 Jun 2012 21:43:13 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Regular Expression
Message-Id: <mcctt7h7rb6lmik0ttch28m352s4p5taio@4ax.com>
Cal Dershowitz <cal@example.invalid> wrote:
>It's too hard for me, jue. At the risk of sounding glib about valuable
>information, if I really don't get the ? character in regex'es,
Well, that is yet another totally different can of worms. And again it
has different meaing depending upon where it is used.
jue
------------------------------
Date: Sun, 17 Jun 2012 22:49:22 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: Regular Expression
Message-Id: <N8mdnYJZItvMLkPSnZ2dnUVZ_qednZ2d@supernews.com>
On 06/17/2012 10:41 PM, Jürgen Exner wrote:
> Cal Dershowitz<cal@example.invalid> wrote:
>> On 06/16/2012 10:26 PM, Jürgen Exner wrote:
>>> Cal Dershowitz<cal@example.invalid> wrote:
>>>> my ($ext) = $name =~ /([^.]*)$/;
>>
>> That one was super hard, with the carat not meaning what it usually does
>
> Actually coming to think of it, no. Or rather sort of.
> The special meaning you seem to be thinking of as anchor at the
> beginning of the string happens only if the carat is the very first
> character in the RE. Otherwise it is a normal character with no special
> meaning except as first character in a character class (I hope I got
> that right from memory).
>
>> and the . as well. Good reading here:
>
> Most characters loose their special meaning in a character class
>
> jue
ah, so.
--
------------------------------
Date: Mon, 18 Jun 2012 10:02:32 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Regular Expression
Message-Id: <slrnjtto4o.fln.hjp-usenet2@hrunkner.hjp.at>
On 2012-06-18 04:41, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Cal Dershowitz <cal@example.invalid> wrote:
>>On 06/16/2012 10:26 PM, Jürgen Exner wrote:
>>> Cal Dershowitz<cal@example.invalid> wrote:
>>>> my ($ext) = $name =~ /([^.]*)$/;
>>
>>That one was super hard, with the carat not meaning what it usually does
>
> Actually coming to think of it, no. Or rather sort of.
> The special meaning you seem to be thinking of as anchor at the
> beginning of the string happens only if the carat is the very first
> character in the RE. Otherwise it is a normal character with no special
> meaning except as first character in a character class (I hope I got
> that right from memory).
Nope. The ^ has this meaning independently of its position in the RE. Of
course, if it isn't the first character it can only match if you use the
/m modifier.
#!/usr/bin/perl
use warnings;
use strict;
use re 'debug';
my $s = "aaa^bbb";
if ($s =~ /a^b/) {
print "<$&>\n";
} else {
print "no match\n";
}
__END__
Compiling REx "a^b"
Final program:
1: EXACT <a> (3)
3: BOL (4)
4: EXACT <b> (6)
6: END (0)
anchored "ab" at 0 (checking anchored) minlen 2
Guessing start of match in sv for REx "a^b" against "aaa^bbb"
Did not find anchored substr "ab"...
Match rejected by optimizer
no match
Freeing REx: "a^b"
>>and the . as well. Good reading here:
>
> Most characters loose their special meaning in a character class
Yes.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Mon, 18 Jun 2012 02:44:36 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Regular expression
Message-Id: <f2utt71aq6qeb05mkp470jj7lvib849acv@4ax.com>
Cal Dershowitz <cal@example.invalid> wrote:
>On 06/17/2012 10:35 PM, Jürgen Exner wrote:
>> Cal Dershowitz<cal@example.invalid> wrote:
>>
>>> ... but I still don't understand why deleted material is not also
>>> returned in this idiom:
>>>
>>> my ($ext) = $name =~ /([^.]*)$/;
>Do I understand correctly that this is a "greedy" comparison?
If you mean greedy match, then yes, the '*' operator is greedy by
nature.
jue
------------------------------
Date: Mon, 18 Jun 2012 13:44:44 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Regular Expression
Message-Id: <sek3b9-a7p1.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2012-06-18 04:41, Jürgen Exner <jurgenex@hotmail.com> wrote:
> >
> > Actually coming to think of it, no. Or rather sort of.
> > The special meaning you seem to be thinking of as anchor at the
> > beginning of the string happens only if the carat is the very first
> > character in the RE. Otherwise it is a normal character with no special
> > meaning except as first character in a character class (I hope I got
> > that right from memory).
IIRC this is a POSIX BRE (mis)feature. It's not usual elsewhere.
> Nope. The ^ has this meaning independently of its position in the RE. Of
> course, if it isn't the first character it can only match if you use the
> /m modifier.
Or at the start of an alternation branch that can match at the start of
the string.
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 3718
***************************************
