[32313] in Perl-Users-Digest
Perl-Users Digest, Issue: 3580 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jan 2 21:09:31 2012
Date: Mon, 2 Jan 2012 18:09:09 -0800 (PST)
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, 2 Jan 2012 Volume: 11 Number: 3580
Today's topics:
Re: Does an "external authentication" package exist? (Otto J. Makela)
Re: Opening Unicode files? (Tim McDaniel)
POD module synopses? (Seymour J.)
Re: POD module synopses? <ben@morrow.me.uk>
Re: POD module synopses? (Seymour J.)
Re: POD module synopses? <ben@morrow.me.uk>
Re: POD module synopses? (Seymour J.)
Re: POD module synopses? <ben@morrow.me.uk>
Re: regexp for matching a string with mandatory undersc <rweikusat@mssgmbh.com>
Strange behavior of 'Alternative capture group numberin <gypark@gmail.com>
Re: Strange behavior of 'Alternative capture group numb sln@netherlands.com
Re: Strange behavior of 'Alternative capture group numb <ben@morrow.me.uk>
Re: Strange behavior of 'Alternative capture group numb <gypark@gmail.com>
why the loop-break after pattern-matching <dn.perl@gmail.com>
Re: why the loop-break after pattern-matching <dn.perl@gmail.com>
Re: why the loop-break after pattern-matching <news@lawshouse.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 02 Jan 2012 10:07:54 +0200
From: om@iki.fi (Otto J. Makela)
Subject: Re: Does an "external authentication" package exist?
Message-Id: <ccy5tqsf1h.fsf@avosetti.csc.fi>
om@iki.fi (Otto J. Makela) wrote:
> Is there a package implementing generalized "external authentication",
> which would combine multiple alternatives like OpenID (including Google
> identity), Facebook, Twitter etc.?
It seems one of the few choices is to use:
http://jvance.com/pages/JQueryOpenIDPlugin.xhtml
--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */
------------------------------
Date: Mon, 2 Jan 2012 04:33:11 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Opening Unicode files?
Message-Id: <jdrc27$t53$1@reader1.panix.com>
In article <7v4lf7lr7g2ro357f5q6prbesdlo29u34f@4ax.com>,
<r.mariotti@fdcx.net> wrote:
>On Tue, 27 Dec 2011 21:19:00 +0000 (UTC), Ilya Zakharevich
><nospam-abuse@ilyaz.org> wrote:
>>Same question as to the other answer: does it ship with Perl? And I
>>do not want any guessing; I want a very deterministic procedure...
>
>Do as all perl mongers do - use CPAN to locate, download and install
>the needed function.
>
>$>perl -MCPAN -e shell
I was a maintainer of servers at previous jobs and could do that for
the system. But not at my current job, and if I wanted to do it for a
shared script, I don't know yet how receptive they would be to a
request. It's why I "use constant" instead of a more modern and
convenient module.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 01 Jan 2012 20:45:49 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: POD module synopses?
Message-Id: <4f010c4d$2$fuzhry+tra$mr2ice@news.patriot.net>
While in theory the SYNOPSIS section of a module's POD has a one line
description, in practice it's much longer, typically containing a
description of the modules parameters or other brief usage
information. In perl 5.8 the name section had a short description
after the name that served the purpose of what might naïvely have
expect from the synopsis. The pod2ipf utility relied on those short
description to construct heading tags that fed into an automatic table
of contents.
In perl 5.10.0, some of the NAME sections contain *only* the name.
This causes pod2ipf to fail[1] entirely and is the reason that the
HTML documentation from perldoc.perl.org has entries in Core Modules
like "CPANPLUS::Backend - CPANPLUS::Backend" instead of
"CPANPLUS::Backend - Object-oriented interface for CPAN++".
Is this something that could be legitimately reported as a bug?
[1] with 27 "bad name" messages for CPANPLUS::* and 1 for each of
Log::Message::Simple, Object::Accessor, and Term::UI::History.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Mon, 2 Jan 2012 02:47:11 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: POD module synopses?
Message-Id: <fei7t8-vit.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> While in theory the SYNOPSIS section of a module's POD has a one line
> description, in practice it's much longer, typically containing a
> description of the modules parameters or other brief usage
> information.
What gave you that idea? The SYNOPSIS section of a POD manual is
equivalent to the same section in a Unix man page, which normally
looks something like
SYNOPSIS
#include <fcntl.h>
int
open(const char *path, int flags, ...);
Not quite the same as the brief example of use in most Perl
documentation, but pretty close.
> In perl 5.8 the name section had a short description
> after the name that served the purpose of what might naïvely have
> expect from the synopsis. The pod2ipf utility relied on those short
> description to construct heading tags that fed into an automatic table
> of contents.
>
> In perl 5.10.0, some of the NAME sections contain *only* the name.
Strictly, this isn't an issue with 5.10, but with some of the CPAN
modules bundled with the 5.10 distribution which weren't in the 5.8
distribution. This isn't just pedantry: if you're going to report a bug,
it would probably be best to report it to the maintainer of the CPAN
module rather than to p5p.
> This causes pod2ipf to fail[1] entirely and is the reason that the
> HTML documentation from perldoc.perl.org has entries in Core Modules
> like "CPANPLUS::Backend - CPANPLUS::Backend" instead of
> "CPANPLUS::Backend - Object-oriented interface for CPAN++".
Does pod2ipf actually fail (refuse to produce any output) or does it
just give warnings? If it fails it should be easy enough to change it so
it substitutes something sensible (as perldoc.perl.org does) and carries
on.
> Is this something that could be legitimately reported as a bug?
I think so, yes, though I wouldn't hold my breath for anyone to fix it
unless you supply a patch. Unfortunately, for historical reasons, the
only information on the expected format of a POD manual is in the
documentation for pod2man. While it does say there that the NAME section
should be a single line, in two parts, separated by ' - ', and that
indexing systems may break if it's not, it's not surprising a lot of
people never find it.
Ben
------------------------------
Date: Mon, 02 Jan 2012 01:38:21 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: POD module synopses?
Message-Id: <4f0150dd$2$fuzhry+tra$mr2ice@news.patriot.net>
In <fei7t8-vit.ln1@anubis.morrow.me.uk>, on 01/02/2012
at 02:47 AM, Ben Morrow <ben@morrow.me.uk> said:
>What gave you that idea?
The Dromedary. On p. 644 it[1] say "A one line description of what
your program or module does (purportedly)."
>Strictly, this isn't an issue with 5.10, but with some of the CPAN
>modules bundled with the 5.10 distribution which weren't in the 5.8
>distribution. This isn't just pedantry: if you're going to report a
>bug, it would probably be best to report it to the maintainer of the
>CPAN module rather than to p5p.
CPANPLUS is a whole tree of modules. Those that have an AUTHOR section
show Jos Boumans <kane@cpan.org> as the author. Should I assume that
he is the author of all of them and send the bug report to him?
>Does pod2ipf actually fail (refuse to produce any output) or does it
>just give warnings?
Yes an no. It fails to extract descriptive text for the TOC, but would
have generated output were it not for an unrelated issue.
>While it does say there that the NAME section
>should be a single line, in two parts, separated by ' - ', and that
>indexing systems may break if it's not, it's not surprising a lot of
>people never find it.
What I found surprising was the the hyphen and descriptive text were
in CPANPLUS for 5.8 but not for 5.10; I have no idea why it was
removed.
[1]3rd edition
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 3 Jan 2012 00:00:10 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: POD module synopses?
Message-Id: <a1t9t8-d7g1.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <fei7t8-vit.ln1@anubis.morrow.me.uk>, on 01/02/2012
> at 02:47 AM, Ben Morrow <ben@morrow.me.uk> said:
>
> >What gave you that idea?
>
> The Dromedary. On p. 644 it[1] say "A one line description of what
> your program or module does (purportedly)."
...OK. That's not right. That's what NAME is for; and since these
conventions were inherited from Unix manpages, I expect they've been
around longer than perl has. The modules distributed with 5.005, before
the 3rd Camel was published, have SYNOPSIS sections very like the modern
ones.
> >Strictly, this isn't an issue with 5.10, but with some of the CPAN
> >modules bundled with the 5.10 distribution which weren't in the 5.8
> >distribution. This isn't just pedantry: if you're going to report a
> >bug, it would probably be best to report it to the maintainer of the
> >CPAN module rather than to p5p.
>
> CPANPLUS is a whole tree of modules. Those that have an AUTHOR section
> show Jos Boumans <kane@cpan.org> as the author. Should I assume that
> he is the author of all of them and send the bug report to him?
No, you should read the documentation, which says
CONTACT INFORMATION
- Bug reporting: bug-cpanplus@rt.cpan.org
OTOH, someone seems to have got there first:
https://github.com/jib/cpanplus-devel/commit/482e3 .
> >Does pod2ipf actually fail (refuse to produce any output) or does it
> >just give warnings?
>
> Yes an no. It fails to extract descriptive text for the TOC, but would
> have generated output were it not for an unrelated issue.
OK, well, since I doubt you'll be wanting to read the documentation for
CPANPLUS::Backend any time soon I wouldn't worry too much about it.
> >While it does say there that the NAME section
> >should be a single line, in two parts, separated by ' - ', and that
> >indexing systems may break if it's not, it's not surprising a lot of
> >people never find it.
>
> What I found surprising was the the hyphen and descriptive text were
> in CPANPLUS for 5.8 but not for 5.10; I have no idea why it was
> removed.
CPANPLUS wasn't bundled with the core in 5.8. Also, AFAICT,
CPANPLUS::Backend has never had a description in its NAME section.
Perhaps you had a non-standard distribution of 5.8, which someone had
corrected?
Ben
------------------------------
Date: Mon, 02 Jan 2012 20:14:45 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: POD module synopses?
Message-Id: <4f025685$1$fuzhry+tra$mr2ice@news.patriot.net>
In <a1t9t8-d7g1.ln1@anubis.morrow.me.uk>, on 01/03/2012
at 12:00 AM, Ben Morrow <ben@morrow.me.uk> said:
>....OK. That's not right. That's what NAME is for; and since these
>conventions were inherited from Unix manpages, I expect they've been
>around longer than perl has. The modules distributed with 5.005,
>before the 3rd Camel was published, have SYNOPSIS sections very like
>the modern ones.
The 4th edition should be out; if the text hasn't been updated I'll
drop ORA a note. Thanks.
>No, you should read the documentation,
I did, just the wrong part :-(
>OTOH, someone seems to have got there first:
>https://github.com/jib/cpanplus-devel/commit/482e3 .
Thanks. Now I'll have to report the ones with duplicat text and the
ones with no NAME section[1]. There's also a bunch[2] where the name
in the NAME section is not the module name, e.g.,
ExtUtils::Constant::XS has ExtUtils::Constant::Base in the module
name. I'm not sure whether to report those, use the --believe-pod-name
option, or both.
>OK, well, since I doubt you'll be wanting to read the documentation
>for CPANPLUS::Backend any time soon I wouldn't worry too much about
>it.
It's also Log::Message::Simple, Object::Accessor and
Term::UI::History.
>Perhaps you had a non-standard distribution of 5.8, which someone
>had corrected?
I believe that the 5.8.8 was Paul Smedley's OS/2 build; I'm not sure
about 5.00553 and 5.8.2.
[1] CPAN::Debug
CPAN::Debug
CPAN::Queue
CPAN::Tarzip
[2] Checker
Escapes
ExtUtils::Constant::XS
Find
Functions
Getopt::Std
Html
IO::Stringy
InputObjects
LaTeX
MIME::Tools
Man
Module::Build::ModuleInfo
Module::Build::Notes
Net::DNS::RR::DHCID
Net::libnetFAQ
ParseLink
ParseUtils
Parser
Perldoc::ToChecker
Perldoc::ToMan
Perldoc::ToNroff
Perldoc::ToPod
Perldoc::ToRtf
Perldoc::ToText
Perldoc::ToTk
Perldoc::ToXml
PlainText
Plainer
Pod::a2p
Regexp::Common::_support
Select
Simple
Simple::Checker
Simple::Debug
Simple::DumpAsText
Simple::DumpAsXML
Simple::HTML
Simple::HTMLBatch
Simple::LinkSection
Simple::Methody
Simple::PullParser
Simple::PullParserEndToken
Simple::PullParserStartToken
Simple::PullParserTextToken
Simple::PullParserToken
Simple::RTF
Simple::Search
Simple::SimpleTree
Simple::Subclassing
Simple::Text
Simple::TextContent
Simple::XMLOutStream
Text
Text::Abbrev
Text::Color
Text::Overstrike
Text::Termcap
Usage
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 3 Jan 2012 01:52:44 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: POD module synopses?
Message-Id: <ck3at8-u0i1.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
>
> Thanks. Now I'll have to report the ones with duplicat text and the
> ones with no NAME section[1]. There's also a bunch[2] where the name
> in the NAME section is not the module name, e.g.,
> ExtUtils::Constant::XS has ExtUtils::Constant::Base in the module
> name. I'm not sure whether to report those, use the --believe-pod-name
> option, or both.
Well, the name in NAME should match the module name. Otherwise your
index will end up pointing you to different documentation from plain
'perldoc', which would be unnecessarily confusing.
I'm not sure what the --believe-pod-name option does, but if the NAME
and the filename are inconsistent I think you want the filename in the
index.
(That particular case appears to have been fixed as of 5.12.)
> [2] Checker
> Escapes
These don't look like module names to me: are you sure they aren't
actually Pod::Checker and Pod::Escapes? Similarly, most of the others in
your list look to me like modules under Pod::, and I suspect Find and
Functions are actually File::Find and File::Find::Functions.
Cases like Getopt::Std and Text::Abbrev are simply incorrect. Those
modules were derived from perl 4 libraries called getopt.pl and
abbrev.pl, and whoever did the 4->5 conversion put the wrong name in the
POD.
Some of the other cases, like IO::Stringy and Net::libnetFAQ, are simply
documentation with no attached module. Presumably the author didn't feel
an accurate NAME section was important in that case; I would say the
existence of a documentation system like pod2ipf that relies on it being
right is a good reason for fixing it.
Ben
------------------------------
Date: Sun, 01 Jan 2012 15:16:23 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: regexp for matching a string with mandatory underscores
Message-Id: <87pqf3tpvc.fsf@sapphire.mobileactivedefense.com>
Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
> On 2011-12-29, John W. Krahn <jwkrahn@example.com> wrote:
[...]
>> It is actually short for tr/_/_/ which
>> replaces every '_' character with a '_' character and returns the number
>> of replacements made. It has the advantages that it doesn't interpolate
>> and it only does one thing, and does it well.
>
> For which value of "well"? If it is applied to 2GB string, would it
> make a copy of it?
Not when counting or replacing character in a non-UTF8 string.
> If the string is tied to a database entry, would
> it cause a database update?
Maybe, maybe not. That would depend on the implemention of tieing mechanism.
> If the string is shared between fork()ed
> processes, would it become unshared after the operation?
Strings are not shared between forked processes, memory pages are. As
soon as any process tries to write to a shared page, it will get its
own copy for usual COW-implementations.
------------------------------
Date: Sun, 1 Jan 2012 08:59:44 -0800 (PST)
From: Raymundo <gypark@gmail.com>
Subject: Strange behavior of 'Alternative capture group numbering'
Message-Id: <30f07f62-0ed6-434c-9dc1-493306deebad@s10g2000prj.googlegroups.com>
Hello,
At first, I'm sorry that I'm not good at English.
I'm reading "perlretut" (Perl Regular Expression Tutorial) of version
5.14 now:
http://perldoc.perl.org/perlretut.html
While I was reading "Alternative capture group numbering" section,
I wrote a simple test program to practice it myself.
I'm using Strawberry Perl 5.12.3 on Windows XP.
Here is my code:
-----
#!perl
use strict;
use warnings;
while (1) {
my $input = <STDIN>;
chomp $input;
if ( $input =~ /(?|(a)(b)|(c))(d)/ ) {
print "1[$1] 2[$2] 3[$3]\n";
}
}
-----
Here is the result:
-----
abd
1[a] 2[b] 3[d]
cd
Use of uninitialized value $2 in concatenation (.) or string at d:\Temp
\test.pl line 13, <STDIN> line 2.
1[c] 2[] 3[d]
----
Okay. This is what I expected and what the document said. 'd' is
assigned to $3 because the maximum number in the alternative numbering
group is 2.
Then I modified the pattern, only changing the order of two group in
the alternative numbering group:
-----
if ( $input =~ /(?|(c)|(a)(b))(d)/ ) {
-----
This is the result:
-----
abd
Use of uninitialized value $3 in concatenation (.) or string at d:\Temp
\test.pl line 13, <STDIN> line 1.
1[a] 2[d] 3[]
cd
Use of uninitialized value $3 in concatenation (.) or string at d:\Temp
\test.pl line 13, <STDIN> line 2.
1[c] 2[d] 3[]
----
I have no idea why the result differs from the first one.
Why 'd' is in $2, not $3? Where did 'b' of 'abd' go after matching?
Is this a bug? Or is there something that I misunderstand?
Any help would be appreciated.
Thank you.
------------------------------
Date: Sun, 01 Jan 2012 12:32:34 -0800
From: sln@netherlands.com
Subject: Re: Strange behavior of 'Alternative capture group numbering'
Message-Id: <0of1g7hmed0np4jrfrkoe0viudhigjb5a1@4ax.com>
On Sun, 1 Jan 2012 08:59:44 -0800 (PST), Raymundo <gypark@gmail.com> wrote:
>Hello,
>
>At first, I'm sorry that I'm not good at English.
>
>I'm reading "perlretut" (Perl Regular Expression Tutorial) of version
>5.14 now:
>http://perldoc.perl.org/perlretut.html
>
>While I was reading "Alternative capture group numbering" section,
>I wrote a simple test program to practice it myself.
>
>I'm using Strawberry Perl 5.12.3 on Windows XP.
>
>Here is my code:
>-----
>#!perl
>use strict;
>use warnings;
>
>while (1) {
> my $input = <STDIN>;
> chomp $input;
> if ( $input =~ /(?|(a)(b)|(c))(d)/ ) {
> print "1[$1] 2[$2] 3[$3]\n";
> }
>}
>-----
>
>Here is the result:
>-----
>abd
>1[a] 2[b] 3[d]
>cd
>Use of uninitialized value $2 in concatenation (.) or string at d:\Temp
>\test.pl line 13, <STDIN> line 2.
>1[c] 2[] 3[d]
>----
>
>Okay. This is what I expected and what the document said. 'd' is
>assigned to $3 because the maximum number in the alternative numbering
>group is 2.
>
>Then I modified the pattern, only changing the order of two group in
>the alternative numbering group:
>-----
> if ( $input =~ /(?|(c)|(a)(b))(d)/ ) {
>-----
>This is the result:
>-----
>abd
>Use of uninitialized value $3 in concatenation (.) or string at d:\Temp
>\test.pl line 13, <STDIN> line 1.
>1[a] 2[d] 3[]
>cd
>Use of uninitialized value $3 in concatenation (.) or string at d:\Temp
>\test.pl line 13, <STDIN> line 2.
>1[c] 2[d] 3[]
>----
>
>I have no idea why the result differs from the first one.
>Why 'd' is in $2, not $3? Where did 'b' of 'abd' go after matching?
>
>Is this a bug? Or is there something that I misunderstand?
>
Its probably not a bug if you had to program branch reset code,
because the whole thing is buggy and tends to crash at the drop of
a hat.
Using the regex debug mechanism some observations can be noted.
The last branch-reset alternation is labled BRANCH (FAIL).
Apparently, the number of capture buffers in this branch is
NOT counted when calculating the largest number of buffers.
Therefore, the # capture buffer after the branch-reset is the
largest of the branches BEFORE the last branch.
Example:
(?|
(x) ()
|
(c)
|
(a) (b) (r)
)
(d)
Produces this code:
1: BRANCH (13)
2: OPEN1 (4)
4: EXACT <x> (6)
6: CLOSE1 (8)
8: OPEN2 (11)
10: NOTHING (11)
11: CLOSE2 (40)
13: BRANCH (20)
14: OPEN1 (16)
16: EXACT <c> (18)
18: CLOSE1 (40)
20: BRANCH (FAIL)
21: OPEN1 (23)
23: EXACT <a> (25)
25: CLOSE1 (27)
27: OPEN2 (29)
29: EXACT <b> (31)
31: CLOSE2 (33)
33: OPEN3 (35)
35: EXACT <r> (37)
37: CLOSE3 (40)
39: TAIL (40)
40: OPEN3 (42)
42: EXACT <d> (44)
44: CLOSE3 (46)
46: END (0)
You can see that (d) is capture buffer 3, but it should be 4.
So the simple solution is that the largest number of capture buffers
should not be in the last branch.
There are a couple of ways around this.
1 - Pad a different branch with a NOTHING capture group.
(?|
(c) ()
| (a)(b)
)
(d)
or,
2 - Move the largest number of captures into another branch.
(?|
(a)(b)
| (c)
)
(d)
This is just an observation that seems to hold true.
In my mind, branch-reset in Perl or any PCRE engine is just
one big bug, and should be avoided.
-sln
------------------------------
Date: Sun, 1 Jan 2012 22:16:43 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Strange behavior of 'Alternative capture group numbering'
Message-Id: <bj27t8-jh03.ln1@anubis.morrow.me.uk>
Quoth sln@netherlands.com:
> On Sun, 1 Jan 2012 08:59:44 -0800 (PST), Raymundo <gypark@gmail.com> wrote:
>
> >Then I modified the pattern, only changing the order of two group in
> >the alternative numbering group:
> >-----
> > if ( $input =~ /(?|(c)|(a)(b))(d)/ ) {
> >-----
> >This is the result:
> >-----
> >abd
> >Use of uninitialized value $3 in concatenation (.) or string at d:\Temp
> >\test.pl line 13, <STDIN> line 1.
> >1[a] 2[d] 3[]
> >cd
> >Use of uninitialized value $3 in concatenation (.) or string at d:\Temp
> >\test.pl line 13, <STDIN> line 2.
> >1[c] 2[d] 3[]
> >----
> >
> >I have no idea why the result differs from the first one.
> >Why 'd' is in $2, not $3? Where did 'b' of 'abd' go after matching?
> >
> >Is this a bug? Or is there something that I misunderstand?
>
> Its probably not a bug if you had to program branch reset code,
> because the whole thing is buggy and tends to crash at the drop of
> a hat.
It looks to me like a bug in perl, and it appears to have been fixed in
5.14.
If you have any other instances of (?|) causing problems (that persist
in 5.14), and certainly if you have any examples of crashes, you should
report them with perlbug.
Ben
------------------------------
Date: Sun, 1 Jan 2012 15:57:21 -0800 (PST)
From: Raymundo <gypark@gmail.com>
Subject: Re: Strange behavior of 'Alternative capture group numbering'
Message-Id: <dfc43890-b92b-4520-9890-39284f335a46@g19g2000pri.googlegroups.com>
On 1=EC=9B=942=EC=9D=BC, =EC=98=A4=EC=A0=847=EC=8B=9C16=EB=B6=84, Ben Morro=
w <b...@morrow.me.uk> wrote:
> Quoth s...@netherlands.com:
>
>
> It looks to me like a bug in perl, and it appears to have been fixed in
> 5.14.
>
> If you have any other instances of (?|) causing problems (that persist
> in 5.14), and certainly if you have any examples of crashes, you should
> report them with perlbug.
>
> Ben
Thank you, sln and Ben.
I've posted the same question on my twitter, and received replies
saying
that 5.14 shows correct results. One of my follows sent me this link:
http://perl5.git.perl.org/perl.git/commit/fd4be6f07df0e6a021290ef721c5d7355=
0e0248c
Happy New Year~ :-)
G.Y.Park from South Korea
------------------------------
Date: Sat, 31 Dec 2011 23:44:06 -0800 (PST)
From: "dn.perl@gmail.com" <dn.perl@gmail.com>
Subject: why the loop-break after pattern-matching
Message-Id: <9e5147a4-9016-4285-9049-ae46ba9a0fd8@v24g2000prn.googlegroups.com>
Here is the code:
#!/usr/local/bin/perl
use strict ;
use warnings ;
my $counter = 1;
my $log = "[pattern number-405] check" ;
print "log is:$log\n" ;
while ( $log =~ /(pattern)( \S+-\d+)+/ig )
{
my $match = $& ; ## $& is the str yielded by the last pattern
match
$match =~ s/^\S+ // ; # remove first word
print "match is $match\n" ;
last if $counter++ > 25 ;
}
print "log is:$log\n" ;
# - - - - - - - - - - -
Why does the loop break after just the first pass? I would expect the
while condition to never change in this patch.
------------------------------
Date: Sun, 1 Jan 2012 00:08:37 -0800 (PST)
From: "dn.perl@gmail.com" <dn.perl@gmail.com>
Subject: Re: why the loop-break after pattern-matching
Message-Id: <3fd9ea02-3bda-4899-8814-82a54ce27bda@e8g2000prb.googlegroups.com>
>
> while ( $log =3D~ /(pattern)( \S+-\d+)+/ig )
> {
> =A0 =A0 last if $counter++ > 25 ;
> }
>
> print "val is:$counter\n" ;
> # - - - - - - - - =A0- - -
>
> Why does the loop break after just the first pass?
>
Well, apparently in a scalar context, the 'g' option remembers where
it had left off the pattern-matching the last time and takes it up
from that point. !!!
------------------------------
Date: Sun, 01 Jan 2012 11:14:42 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: why the loop-break after pattern-matching
Message-Id: <1aadna6VhvG_3Z3SnZ2dnUVZ8s2dnZ2d@giganews.com>
On 01/01/12 08:08, dn.perl@gmail.com wrote:
> Well, apparently in a scalar context, the 'g' option remembers where
> it had left off the pattern-matching the last time and takes it up
> from that point. !!!
If I had a pound for every time the very act of asking for help on a
problem prompts one to find the solution ...
But I wouldn't code "g" at all in this case (unless your real data
contains multiple copies of the pattern), and my practice is to use $1
(and $2, $3 etc if necessary) to collect the results of the matches
rather than $&. Also, what are you going to do if your pattern doesn't
match?
I amused myself on this Neew Year's morning by re-writing your code a
little; I'm not an experienced Perl coder so having made suggestions to
you I'm open to them myself.
#!/usr/bin/perl
use strict;
use warnings;
my $counter = 0;
while ( my $line = <DATA> ) {
$counter++;
if ( $line =~ /pattern( \S+-\d+)+/i ) {
print "Log is $1\n";
}
else {
chomp $line;
warn "Bad input line no $counter: '$line'\n";
}
}
print "$counter lines read\n";
__DATA__
[pattern number-405] check
Rubbish
[pattern number-406] check
[pattern number-407] check
--
Henry Law Manchester, England
------------------------------
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 3580
***************************************
