[23596] in Perl-Users-Digest
Perl-Users Digest, Issue: 5803 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 14 14:06:08 2003
Date: Fri, 14 Nov 2003 11:05:20 -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 Fri, 14 Nov 2003 Volume: 10 Number: 5803
Today's topics:
ALRM weirdness in Perl 5.8.0 <admin@asarian-host.net>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: arrange form data in same order as on form <asu1@c-o-r-n-e-l-l.edu>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: arrange form data in same order as on form <asu1@c-o-r-n-e-l-l.edu>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: arrange form data in same order as on form <asu1@c-o-r-n-e-l-l.edu>
Re: arrange form data in same order as on form <asu1@c-o-r-n-e-l-l.edu>
Re: arrange form data in same order as on form <flavell@ph.gla.ac.uk>
Re: arrange form data in same order as on form <REMOVEsdnCAPS@comcast.net>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: Can you reliably make a reference to a capture buff <pinyaj@rpi.edu>
Re: Can you reliably make a reference to a capture buff (Anno Siegel)
Re: Dynamic regexp <winston_smith@linuxmail.org>
Re: Dynamic regexp <roman@sky.lviv.ua>
Re: Dynamic regexp <grazz@pobox.com>
Re: Dynamic regexp (Anno Siegel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 14 Nov 2003 17:05:20 +0100
From: "Mark" <admin@asarian-host.net>
Subject: ALRM weirdness in Perl 5.8.0
Message-Id: <Jsedna2MfKXXYCmiRVn-sA@giganews.com>
Using Perl 5.8.0, with threads, I am having the darndest problem getting
ALRM to work.
First of all, setting off an ALRM would crash the program (a Milter)
altogether. Doing a wee research revealed, that, for reasons unknown, it is
imperative you set this BEFORE you go threading:
$SIG{'ALRM'} = 'DEFAULT';
So I did. And, indeed, the crashes stopped. Weird by itself, but something I
can live with. :) What I cannot live with, however, is that my ALRM is still
not triggered! The actual code using the ALRM is a subroutine checking the
AVP daemon for viruses. Like so:
-----------------------------
#!/usr/local/threadedperl/bin/perl
if ($avp_daemon_up) {
eval {
local $SIG{ALRM} = sub { die "bla" };
alarm 5;
sleep 8;
print $client "<0>" . strftime ("%b %e %H:%M:%S", ...
yadda, yadda, yadda
alarm 0;
close ($client);
};
$virus_result_code = ($rval & 0x0F);
}
-----------------------------
Nothing top-notch, really. The "sleep 8;" is there only for the test, of
course. But the ALRM is never triggered! As if totally non-existent. I can
set "sub { exit 1 }", for all that matter, and still nothing happens.
I tried a zillion permutations, with or wihout 'local', either set in
advance or only local, but it makes no difference. Either the ALRM totally
crashes the program, or is totally ignored. Maybe it is related to that
whole 'safe signals' business. And there once was a brilliant man here who
posted a way to get your 'old-style' signals back; are you still out there?
:)
Is there anyone out here who can shed some light on this? A really need my
ALRM back at that location.
Thanks,
- Mark
------------------------------
Date: Fri, 14 Nov 2003 15:21:27 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp2opd$1jtuap$1@ID-184292.news.uni-berlin.de>
Eric J. Roode wrote:
> Gunnar Hjalmarsson wrote:
>> Still don't understand what it is that makes the above code
>> "buggy".
>
> [OP's posted code]:
>
>> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
>> @pairs = split(/&/, $buffer);
>> foreach $pair (@pairs) {
>> ($name, $value) = split(/=/, $pair);
>> $value =~ tr/+/ /;
>> $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
>> $FORM{$name} = $value;
Note that my initial comment only referred to the two first of those
lines.
> 1. The read() may fail. No check is made to see if it does.
>
> 2. This code does not handle GET requests.
>
> 3. CGI parameters may be separated by semicolons instead of
> ampersands.
>
> 4. If a faulty browser fails to encode "=" with a % escape, and
> that "=" is part of a form variable value, this code will drop that
> portion of the value. I've seen browsers do this. split() should
> use the limit parameter.
>
> 5. No limit is placed on the quantity of data read, opening the
> script to possible DOS attack.
Thanks for that list over CGI.pm features.
To me, a piece of code that does what it's _intended_ to do is not
"buggy". It may have _limitations_, but limitations and bugs are not
the same thing.
If I want my program to print today's date in ISO 8601 format, I may
use this code:
my $time = time;
sub myDate {
my @t = (gmtime $time)[3..5];
sprintf '%d-%02d-%02d', $t[2] += 1900, ++$t[1], $t[0];
}
print myDate();
I could have used your Time::Format module instead, but if I don't
need a variety of date and time formats in my program, I wouldn't
likely have done so.
Time::Format includes some nice tools for time formating, no doubt.
Nevertheless, that fact wouldn't make you claim that my myDate()
function is "buggy", right?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 14 Nov 2003 14:37:04 GMT
From: "A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns943361D85A34Aasu1cornelledu@132.236.56.8>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp2opd$1jtuap$1@ID-
184292.news.uni-berlin.de:
>> Gunnar Hjalmarsson wrote:
> To me, a piece of code that does what it's _intended_ to do is not
> "buggy". It may have _limitations_, but limitations and bugs are not
> the same thing.
On the other hand, there is usually a difference between what the author
of the code intends it to do and what the user of the code thinks it
does. In the case of OP's code, it had not been written by him (as I had
surmised) and we cannot expect the OP to have had full understanding of
the 'limitations' of the code. Hence my suggestion to either roll his own
paying attention to details (if this is for a learning exercise) or use
CGI.pm if he just wants to parse a form and feel safe.
> If I want my program to print today's date in ISO 8601 format, I may
> use this code:
>
> my $time = time;
> sub myDate {
> my @t = (gmtime $time)[3..5];
> sprintf '%d-%02d-%02d', $t[2] += 1900, ++$t[1], $t[0];
> }
> print myDate();
...
> Time::Format includes some nice tools for time formating, no doubt.
> Nevertheless, that fact wouldn't make you claim that my myDate()
> function is "buggy", right?
Is it possible to bring a web server down using your myDate function?
Sinan.
--
A. Sinan Unur
asu1@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:uce@ftc.gov
------------------------------
Date: Fri, 14 Nov 2003 16:00:24 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp2r2h$1jhuen$1@ID-184292.news.uni-berlin.de>
A. Sinan Unur wrote:
> Gunnar Hjalmarsson wrote:
>> To me, a piece of code that does what it's _intended_ to do is
>> not "buggy". It may have _limitations_, but limitations and bugs
>> are not the same thing.
>
> On the other hand, there is usually a difference between what the
> author of the code intends it to do and what the user of the code
> thinks it does. In the case of OP's code, it had not been written
> by him (as I had surmised) and we cannot expect the OP to have had
> full understanding of the 'limitations' of the code.
If you don't know what you are doing, don't do it. I can agree on
that, not least when it comes to CGI.
> Hence my suggestion to either roll his own paying attention to
> details (if this is for a learning exercise) or use CGI.pm if he
> just wants to parse a form and feel safe.
"Safe"??? That's another annoying thing with the arguments used by the
'CGI.pm fan club'. Very often you give the impression that by using
CGI.pm, you don't need to bother about anything, since other very
experienced programmers have already taken care of it for you.
You know very well that there are security implications with CGI
scripts, whether you use CGI.pm or not. So why on earth do you talk
about feeling "safe"?
>> Time::Format includes some nice tools for time formating, no
>> doubt. Nevertheless, that fact wouldn't make you claim that my
>> myDate() function is "buggy", right?
>
> Is it possible to bring a web server down using your myDate
> function?
Probably not. But it can be done with a CGI script, even if CGI.pm is
used to parse form data.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 14 Nov 2003 15:17:10 GMT
From: "A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns943368A4D40E6asu1cornelledu@132.236.56.8>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp2r2h$1jhuen$1@ID-
184292.news.uni-berlin.de:
> A. Sinan Unur wrote:
>> Gunnar Hjalmarsson wrote:
...
>> Hence my suggestion to either roll his own paying attention to
>> details (if this is for a learning exercise) or use CGI.pm if he
>> just wants to parse a form and feel safe.
>
> "Safe"??? That's another annoying thing with the arguments used by the
> 'CGI.pm fan club'. Very often you give the impression that by using
> CGI.pm, you don't need to bother about anything, since other very
> experienced programmers have already taken care of it for you.
Well, maybe I should have fully spelt it out. I meant "feel safe that the
nuts and bolts of parsing the form is properly taken care of". I did not
mean to imply that just by sticking a use CGI; you never have to worry
about the security implications of running a program using untrusted
data. But then, that is not a Perl issue.
>>> Time::Format includes some nice tools for time formating, no
>>> doubt. Nevertheless, that fact wouldn't make you claim that my
>>> myDate() function is "buggy", right?
>>
>> Is it possible to bring a web server down using your myDate
>> function?
>
> Probably not. But it can be done with a CGI script, even if CGI.pm is
> used to parse form data.
It can be done in a CGI script regardless of the programming language and
libraries used. But the culprit should not be that you blindly copied
code that has been in circulation at least since 1996 instead of using a
peer-reviewed module.
Sinan.
--
A. Sinan Unur
asu1@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:uce@ftc.gov
------------------------------
Date: Fri, 14 Nov 2003 16:44:16 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp2tkt$1kh0be$1@ID-184292.news.uni-berlin.de>
A. Sinan Unur wrote:
> [Bringing a web server down] can be done in a CGI script regardless
> of the programming language and libraries used. But the culprit
> should not be that you blindly copied code that has been in
> circulation at least since 1996 instead of using a peer-reviewed
> module.
Maybe we can finally reach an agreement about this? :)
IMO, the keyword above is "blindly". You should of course never copy
and use *any* code fragment if you don't know how it works. Doing so
cannot be an acceptable alternative to using an established module.
Isn't the real problem that many beginners copy pieces of code that
they don't *understand*, and use them in production code? If so,
wouldn't it be better to say just that, rather than claiming that
every occurrence of code that parses form data is bad or buggy by
definition?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 14 Nov 2003 16:25:13 GMT
From: "A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns9433742CC3FC3asu1cornelledu@132.236.56.8>
"bbxrider" <bxtrap01@comcast.net> wrote in
news:Sf_sb.145049$9E1.742137@attbi_s52:
> what is 'top-post' ???
Google is your friend.
http://www.xs4all.nl/%7ewijnands/nnq/nquote.html (see Q.7)
Sinan.
------------------------------
Date: 14 Nov 2003 16:47:55 GMT
From: "A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns94337805E8E58asu1cornelledu@132.236.56.8>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp2tkt$1kh0be$1@ID-
184292.news.uni-berlin.de:
> A. Sinan Unur wrote:
>> [Bringing a web server down] can be done in a CGI script regardless
>> of the programming language and libraries used. But the culprit
>> should not be that you blindly copied code that has been in
>> circulation at least since 1996 instead of using a peer-reviewed
>> module.
>
> Maybe we can finally reach an agreement about this? :)
>
> IMO, the keyword above is "blindly". You should of course never copy
> and use *any* code fragment if you don't know how it works. Doing so
> cannot be an acceptable alternative to using an established module.
Agreed.
> Isn't the real problem that many beginners copy pieces of code that
> they don't *understand*, and use them in production code? If so,
> wouldn't it be better to say just that, rather than claiming that
> every occurrence of code that parses form data is bad or buggy by
> definition?
Well, I have not claimed every occurence of such code is buggy by
definition. I reacted to the read and query string parsing bugs (later
retracted my objection to the latter). In this specific instance, I was
reacting to code that I have seen posted numerous times with no
indication that the poster was aware of potential pitfalls.
Sinan.
------------------------------
Date: Fri, 14 Nov 2003 16:13:22 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: arrange form data in same order as on form
Message-Id: <Pine.LNX.4.53.0311141556360.9701@ppepc56.ph.gla.ac.uk>
On Fri, 14 Nov 2003, Gunnar Hjalmarsson wrote:
> To me, a piece of code that does what it's _intended_ to do is not
> "buggy". It may have _limitations_, but limitations and bugs are not
> the same thing.
I don't think there's any real disagreement over that, unless the
limitation under discussion was in the department of "inability of the
code to protect itself against dangerous input from the client", in
which case I'd rate it as not only a limitation but also a bug.
> If I want my program to print today's date in ISO 8601 format, I may
> use this code:
However, it's a fact of programming life that the initial design and
implementation often represents only a tiny fraction of the software's
total lifetime support implications. So a program that can only
produce a single date format might very well later be called upon to
produce a different format, or to correctly report the time in someone
else's timezone, or whatever. So an initial design which is capable
of being easily extended to do these things may offer some real
advantages over one that will need additional one-off code development
to achieve the same result, in terms of later maintenance commitments.
Case in point: a few days after the end of European daylight savings
time this year, I had occasion to deal with a USAn videoconference
booking system. It thought that the clock time in the UK was BST (it
was not) and numerically the same as in Geneva(CH) (it was not) and
an hour away from the time in Hamburg(DE) (it got that much right).
When I reported the discrepancy, I was told "the software can be
tweaked". I'm sure it can, but why would it need to? Computer
systems in the various locations _know_ the correct time and timezone
for any supported locale - their sysadmins do not need to "tweak"
them. Evidently the company that implemented the videoconferencing
server had re-invented a square wheel, no?
------------------------------
Date: Fri, 14 Nov 2003 11:21:27 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns94337DC4825E4sdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp2opd$1jtuap$1@ID-
184292.news.uni-berlin.de:
> Eric J. Roode wrote:
>> Gunnar Hjalmarsson wrote:
>>> Still don't understand what it is that makes the above code
>>> "buggy".
>>
>> [OP's posted code]:
>>
>>> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
>>> @pairs = split(/&/, $buffer);
...
>
> Note that my initial comment only referred to the two first of those
> lines.
Well, even just those two lines are the subject of four of my five
arguments against the whole code block. :-)
> To me, a piece of code that does what it's _intended_ to do is not
> "buggy". It may have _limitations_, but limitations and bugs are not
> the same thing.
Agreed.
> If I want my program to print today's date in ISO 8601 format, I may
> use this code:
>
> my $time = time;
> sub myDate {
> my @t = (gmtime $time)[3..5];
> sprintf '%d-%02d-%02d', $t[2] += 1900, ++$t[1], $t[0];
> }
> print myDate();
>
> I could have used your Time::Format module instead, but if I don't
> need a variety of date and time formats in my program, I wouldn't
> likely have done so.
>
> Time::Format includes some nice tools for time formating, no doubt.
> Nevertheless, that fact wouldn't make you claim that my myDate()
> function is "buggy", right?
Your example is a bit simplistic. It is indeed simple to roll one's own
date-formatting code. Your code above has no obvious bugs that jump out
and catch my attention. It is limited in that its format is hard-coded,
but so what? That maybe sufficient for your needs, and as you point out,
a limitation is not a bug.
However, the OP (and hundreds of others like him) were apparently under
the impression that their code would be sufficient to "parse CGI input
parameters". In many cases it would, but in many cases not. And it is
not so simple to write robust CGI input handling code. It's not rocket
science -- but it's a silly wheel to reinvent.
<imho>
It's foolish to write twenty or thirty lines of robust CGI-parsing code
and include it in every CGI you write. It's more foolish to write five
or ten lines of crappy CGI-parsing code and include it in every CGI
program you write. It's much less foolish to write your own robust CGI-
parsing code, wrap it up in a nice module, and use that module from your
own CGI programs.
It's even less foolish to just use the already-written, combat-tested
CGI.pm module. It's a no-brainer.
</imho>
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP7UOl2PeouIeTNHoEQLzYACgx8IVkq5OBGar98dChVQ46a8dggQAoLTb
wZwJIm1P6iVuyABxxUFgK3j1
=hXcR
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 14 Nov 2003 18:34:23 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp343m$1jm4u0$1@ID-184292.news.uni-berlin.de>
A. Sinan Unur wrote:
> Gunnar Hjalmarsson wrote:
>> Isn't the real problem that many beginners copy pieces of code
>> that they don't *understand*, and use them in production code? If
>> so, wouldn't it be better to say just that, rather than claiming
>> that every occurrence of code that parses form data is bad or
>> buggy by definition?
>
> Well, I have not claimed every occurence of such code is buggy by
> definition.
No, you haven't. My apologies for that.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 14 Nov 2003 18:34:28 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp343s$1hmto7$1@ID-184292.news.uni-berlin.de>
Alan J. Flavell wrote:
> Gunnar Hjalmarsson wrote:
>> To me, a piece of code that does what it's _intended_ to do is
>> not "buggy". It may have _limitations_, but limitations and bugs
>> are not the same thing.
>
> I don't think there's any real disagreement over that, unless the
> limitation under discussion was in the department of "inability of
> the code to protect itself against dangerous input from the
> client", in which case I'd rate it as not only a limitation but
> also a bug.
>
>> If I want my program to print today's date in ISO 8601 format, I
>> may use this code:
>
> However, it's a fact of programming life that the initial design
> and implementation often represents only a tiny fraction of the
> software's total lifetime support implications. So a program that
> can only produce a single date format might very well later be
> called upon to produce a different format, or to correctly report
> the time in someone else's timezone, or whatever. So an initial
> design which is capable of being easily extended to do these things
> may offer some real advantages over one that will need additional
> one-off code development to achieve the same result, in terms of
> later maintenance commitments.
Absolutely. That's things to consider when deciding whether to use a
module, but it has nothing to do with the question if the alternative
contains bugs or not.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 14 Nov 2003 10:17:36 -0500
From: Jeff 'japhy' Pinyan <pinyaj@rpi.edu>
Subject: Re: Can you reliably make a reference to a capture buffer?
Message-Id: <Pine.SGI.3.96.1031114100123.151015B-100000@vcmr-64.server.rpi.edu>
On Fri, 14 Nov 2003, Clint Olsen wrote:
>I tried to return a reference to a capture buffer ($1), and it looks like
>the contents are destroyed out from under me. Is there something special
>about a capture buffer that makes this impossible?
The $<DIGIT> variables are automagically dynamically scoped (like local()
variables). However, when you leave the scope in which they were created,
they revert to their previous value. This is because $1 and its ilk are
merely conduits to get to values, they don't actually hold a value
themselves. They are, in Perl source terms, "magic" variables.
Thus, taking a reference to the conduit, not the value.
"foo" =~ /(.)/;
{
"bar" =~ /(.)/;
$x = \$1;
print "$x, $$x\n"; # SCALAR(0x814ea14), b
}
$y = \$1;
print "$x, $$x\n"; # SCALAR(0x814ea14), f
print "$y, $$y\n"; # SCALAR(0x814ea14), f
--
Jeff Pinyan RPI Acacia Brother #734 2003 Rush Chairman
"And I vos head of Gestapo for ten | Michael Palin (as Heinrich Bimmler)
years. Ah! Five years! Nein! No! | in: The North Minehead Bye-Election
Oh. Was NOT head of Gestapo AT ALL!" | (Monty Python's Flying Circus)
------------------------------
Date: 14 Nov 2003 16:35:29 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Can you reliably make a reference to a capture buffer?
Message-Id: <bp308h$r5g$1@mamenchi.zrz.TU-Berlin.DE>
Jeff 'japhy' Pinyan <pinyaj@rpi.edu> wrote in comp.lang.perl.misc:
> On Fri, 14 Nov 2003, Clint Olsen wrote:
>
> >I tried to return a reference to a capture buffer ($1), and it looks like
> >the contents are destroyed out from under me. Is there something special
> >about a capture buffer that makes this impossible?
>
> The $<DIGIT> variables are automagically dynamically scoped (like local()
> variables).
Yet you go on to show that the $<DIGIT> variables don't behave like localized
variables at all. Your explanation below is fine (as far as I can tell)
but it's unwise to liken the behavior of $<DIGIT> to that of a localized
package variable. The analogy breaks down soon. A reference to a localized
scalar is to the current value, and will not change when the value goes
out of scope. A ref to $1 changes its content all the time, not only
on matches, but also when the block is left where the match occurred.
Anno
> However, when you leave the scope in which they were created,
> they revert to their previous value. This is because $1 and its ilk are
> merely conduits to get to values, they don't actually hold a value
> themselves. They are, in Perl source terms, "magic" variables.
print "Localized package variable:\n";
our $x = 123;
my $ref1 = \ $x;
my $ref2;
{
local $x = 456;
$ref2 = \ $x;
print "inside: $_ -> $$_\n" for $ref1, $ref2;
}
print "outside: $_ -> $$_\n" for $ref1, $ref2;
print "\n";
print "Capture variable:\n";
'123' =~ /(...)/;
$ref1 = \ $1;
{
'456' =~ /(...)/;
$ref2 = \ $1;
print "inside: $_ -> $$_\n" for $ref1, $ref2;
}
print "outside: $_ -> $$_\n" for $ref1, $ref2;
__END__
Localized package variable:
inside: SCALAR(0xff778) -> 123
inside: SCALAR(0xf5578) -> 456
outside: SCALAR(0xff778) -> 123
outside: SCALAR(0xf5578) -> 456
Capture variable:
inside: SCALAR(0x126324) -> 456
inside: SCALAR(0x126324) -> 456
outside: SCALAR(0x126324) -> 123
outside: SCALAR(0x126324) -> 123
------------------------------
Date: Fri, 14 Nov 2003 10:28:28 -0500
From: Winston Smith <winston_smith@linuxmail.org>
Subject: Re: Dynamic regexp
Message-Id: <Bw6tb.15522$IK2.1241062@news20.bellglobal.com>
Hi,
> if ($string =~ s/$rule->[0]/eval qq("$rule->[1]") /ei)
> ...
> I expect this code to be fairly slow
> [ '^HELLO (.*)$', '"BONJOUR $1"']
> ...
> if ($string =~ s/$rule->[0]/$rule->[1]/eei)
I tried both solutions and they work fine. Now I'm bothered just by
Eric's remark that his solution is probably slow. Do you feel the second
solution is faster or is it the same? For the moment I have only a few
rules so I can't tell the difference but this might get important as I
expect to have more than a hundred rules at the end of the project!
Anyway thank you a lot for your help.
------------------------------
Date: Fri, 14 Nov 2003 18:21:09 +0200
From: "Roman Khutkyy" <roman@sky.lviv.ua>
Subject: Re: Dynamic regexp
Message-Id: <bp2v46$30vd$1@news.uar.net>
It's faster, no doubt. Try to check by yourself.
"Winston Smith" <winston_smith@linuxmail.org> wrote in message
news:Bw6tb.15522$IK2.1241062@news20.bellglobal.com...
> Hi,
>
> > if ($string =~ s/$rule->[0]/eval qq("$rule->[1]") /ei)
> > ...
> > I expect this code to be fairly slow
>
> > [ '^HELLO (.*)$', '"BONJOUR $1"']
> > ...
> > if ($string =~ s/$rule->[0]/$rule->[1]/eei)
>
> I tried both solutions and they work fine. Now I'm bothered just by
> Eric's remark that his solution is probably slow. Do you feel the second
> solution is faster or is it the same? For the moment I have only a few
> rules so I can't tell the difference but this might get important as I
> expect to have more than a hundred rules at the end of the project!
>
> Anyway thank you a lot for your help.
>
------------------------------
Date: Fri, 14 Nov 2003 16:40:15 GMT
From: Steve Grazzini <grazz@pobox.com>
Subject: Re: Dynamic regexp
Message-Id: <Pz7tb.33577$bQ3.19220@nwrdny03.gnilink.net>
Winston Smith <winston_smith@linuxmail.org> wrote:
>> if ($string =~ s/$rule->[0]/eval qq("$rule->[1]") /ei)
>> [ '^HELLO (.*)$', '"BONJOUR $1"']
>> ...
>> if ($string =~ s/$rule->[0]/$rule->[1]/eei)
>
> I tried both solutions and they work fine. Now I'm bothered just by
> Eric's remark that his solution is probably slow. Do you feel the second
> solution is faster or is it the same?
There won't be a significant difference.
Using qr// and getting rid of the string eval() would probably speed it
up a bit -- but you'll want to Benchmark it with real rules/data.
@rules = (
[qr/^HELLO (.*)$/ => sub { "BONJOUR $1" }],
# ...
);
foreach $rule (@rules) {
last if $string =~ s/$rule->[0]/$rule->[1]()/ei;
}
--
Steve
------------------------------
Date: 14 Nov 2003 16:51:09 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Dynamic regexp
Message-Id: <bp315t$r5g$2@mamenchi.zrz.TU-Berlin.DE>
Winston Smith <winston_smith@linuxmail.org> wrote in comp.lang.perl.misc:
> Hi,
>
> > if ($string =~ s/$rule->[0]/eval qq("$rule->[1]") /ei)
> > ...
> > I expect this code to be fairly slow
>
> > [ '^HELLO (.*)$', '"BONJOUR $1"']
> > ...
> > if ($string =~ s/$rule->[0]/$rule->[1]/eei)
>
> I tried both solutions and they work fine. Now I'm bothered just by
> Eric's remark that his solution is probably slow. Do you feel the second
> solution is faster or is it the same? For the moment I have only a few
> rules so I can't tell the difference but this might get important as I
> expect to have more than a hundred rules at the end of the project!
For a large-scale project I'd consider the templating modules on CPAN.
They do that kind of thing routinely.
Applying many regexes to all lines of a file is frequently a performance
problem. "perldoc -q many" brings up a pertinent FAQ reply. It doesn't
deal with replacement directly, but it can be used to preselect those
replacements that must be performed on a line.
Anno
------------------------------
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:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
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 V10 Issue 5803
***************************************
