PERL5LIB env variable import possibly broken for large contents onWin32? ( Was: Re: Your CPAN smoker

On Wed, 30 Mar 2011 02:22:32 +0200, perl@0ne.us wrote:

> Hello,
>
> I just got this FAIL report today from CPANTesters:
>
>http://www.cpantesters.org/cpan/report/0ee8eb99-6c5d-1014-a 630-0d8a02da9=
6e1
>
> As you can see, the prereq is correctly recognized by the toolchain
> and loaded - it's even in the lengthy @INC list, BUT when executing the
> test script it seems like @INC disappears somehow? Since I don't know
> the details of your setup I have to assume something is broken.
>
> Can you verify that it's not a problem with just my module? There's
> no easy way to search the cpantesters database for all of your reports
> so I can check to see if you've been sending bad FAILs or not. Can you
> please test my module by hand to see if it really works? Thanks!
>
> I suspect it's something to do with MSWin32 limitations, as I have
> received several other FAILs in the past with the same symptoms as this
> one. However, as I don't have access to a box now I can't quickly test
> my theory out. I have sent an email to the list several weeks ago but
> seems like everyone was busy :(
>
> The subject was "Weird failures from smokers on MSWin32?"
>
> Thanks again for your assistance with this and again, BIG THANKS fo=
r
> running a smoker! :)
>
> ~Apocalypse
>

I reproduced this case and it seems that this might actually be a Perl bu=
g. Situation is as follows:

My CPAN is still 1.9402 and configured to reuse_build_dir.

This means that in order to run a test on a module, it will throw *all* t=
he build dirs in ~/.cpan/build into $ENV{PERL5LIB}, which i understand is=
added to @INC by the perl executable itself. ( http://perldoc.perl.org/p=
erlrun.html#ENVIRONMENT )

Reproduction thus was relatively easy:

Stop the smoker, run cpan, `look` at an affected dist, in my example Para=
ms::Classify and `make test`. In order to make the output more useful i a=
dded debug statements to CPAN.pm and gutted the test suite of Params::Cla=
ssify, replacing it with a single test that tries to use the module and d=
umps environment and INC information. Here's the output:

https://gist.github.com/893981

Of note: The test ( https://gist.github.com/893981#L225 ) clearly has a w=
hole battery of directories in $ENV{PERL5LIB} ( https://gist.github.com/8=
93981#L247 ) which the perl executable can obviously see, including the P=
arams::Classify dir as the very first; since that's a Data::Dumper output=
of %ENV. However @INC remains unchanged by that. ( https://gist.github.c=
om/893981#L579 )

This seems to indicate to me that the perl executable itself is, for what=
ever reason, flat out ignoring the PERL5LIB and/or failing to inject it i=
nto @INC. Other possibilities include Module::Build messing things up or =
the Windows Perl executable exclusively having issues.

I do not know how to further pursue this issue, but will happily provide =
any assistance needed in digging deeper into this.

(And for now will try to at least follow up bugs FAIL reports with proper=
PASSes by periodically cleaning out /build and removing fails from my re=
ports-sent.db.)

--=20
With regards,
Christian Walde

RE: PERL5LIB env variable import possibly broken for large contents

> -----Original Message-----
> From: activeperl-bounces@listserv.ActiveState.com [mailto:activeperl-
> bounces@listserv.ActiveState.com] On Behalf Of Christian Walde
> Sent: 30 March 2011 09:55
> To: perl@0ne.us
> Cc: CPAN Testers Discuss; 'p5p'; activeperl@listserv.activestate.com
> Subject: PERL5LIB env variable import possibly broken for large
> contents on Win32? ( Was: Re: Your CPAN smoker is misconfigured? )
>
> On Wed, 30 Mar 2011 02:22:32 +0200, perl@0ne.us wrote:
>
> > Hello,
> >
> > I just got this FAIL report today from CPANTesters:
> >
> >http://www.cpantesters.org/cpan/report/0ee8eb99-6c5d-1014-a 630-
> 0d8a02da96e1
> >
> > As you can see, the prereq is correctly recognized by the
> toolchain
> > and loaded - it's even in the lengthy @INC list, BUT when executing
> the
> > test script it seems like @INC disappears somehow? Since I don't know
> > the details of your setup I have to assume something is broken.
> >
> > Can you verify that it's not a problem with just my module?
> There's
> > no easy way to search the cpantesters database for all of your
> reports
> > so I can check to see if you've been sending bad FAILs or not. Can
> you
> > please test my module by hand to see if it really works? Thanks!
> >
> > I suspect it's something to do with MSWin32 limitations, as I
> have
> > received several other FAILs in the past with the same symptoms as
> this
> > one. However, as I don't have access to a box now I can't quickly
> test
> > my theory out. I have sent an email to the list several weeks ago but
> > seems like everyone was busy :(
> >
> > The subject was "Weird failures from smokers on MSWin32?"
> >
> > Thanks again for your assistance with this and again, BIG THANKS
> for
> > running a smoker! :)
> >
> > ~Apocalypse
> >
>
> I reproduced this case and it seems that this might actually be a Perl
> bug. Situation is as follows:
>
> My CPAN is still 1.9402 and configured to reuse_build_dir.
>
> This means that in order to run a test on a module, it will throw *all*
> the build dirs in ~/.cpan/build into $ENV{PERL5LIB}, which i understand
> is added to @INC by the perl executable itself. (
> http://perldoc.perl.org/perlrun.html#ENVIRONMENT )
>
> Reproduction thus was relatively easy:
>
> Stop the smoker, run cpan, `look` at an affected dist, in my example
> Params::Classify and `make test`. In order to make the output more
> useful i added debug statements to CPAN.pm and gutted the test suite of
> Params::Classify, replacing it with a single test that tries to use the
> module and dumps environment and INC information. Here's the output:
>
> https://gist.github.com/893981
>
> Of note: The test ( https://gist.github.com/893981#L225 ) clearly has a
> whole battery of directories in $ENV{PERL5LIB} (
> https://gist.github.com/893981#L247 ) which the perl executable can
> obviously see, including the Params::Classify dir as the very first;
> since that's a Data::Dumper output of %ENV. However @INC remains
> unchanged by that. ( https://gist.github.com/893981#L579 )
>
> This seems to indicate to me that the perl executable itself is, for
> whatever reason, flat out ignoring the PERL5LIB and/or failing to
> inject it into @INC. Other possibilities include Module::Build messing
> things up or the Windows Perl executable exclusively having issues.
>
> I do not know how to further pursue this issue, but will happily
> provide any assistance needed in digging deeper into this.
>
> (And for now will try to at least follow up bugs FAIL reports with
> proper PASSes by periodically cleaning out /build and removing fails
> from my reports-sent.db.)

I don't know if this is your problem, but a bit of googling found this.

http://support.microsoft.com/kb/830473

Especially the part about cmd ignoring variables that are longer than its limit.

HTH

P.S. I have not replied to the lists that don't know me from Adam.

--
Brian Raven




Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PERL5LIB env variable import possibly broken for large contents

On Wed, 30 Mar 2011 11:30:59 +0200, Brian Raven wrote:

>> Of note: The test ( https://gist.github.com/893981#L225 ) clearly has a
>> whole battery of directories in $ENV{PERL5LIB} (
>> https://gist.github.com/893981#L247 ) which the perl executable can
>> obviously see, including the Params::Classify dir as the very first;
>> since that's a Data::Dumper output of %ENV. However @INC remains
>> unchanged by that. ( https://gist.github.com/893981#L579 )
>>
>> This seems to indicate to me that the perl executable itself is, for
>> whatever reason, flat out ignoring the PERL5LIB and/or failing to
>> inject it into @INC. Other possibilities include Module::Build messing
>> things up or the Windows Perl executable exclusively having issues.
>
> I don't know if this is your problem, but a bit of googling found this.
>
> http://support.microsoft.com/kb/830473
>
> Especially the part about cmd ignoring variables that are longer than its limit.
>
> HTH
>
> P.S. I have not replied to the lists that don't know me from Adam.

At first i thought that was the case too. But the fact that the perl executable knows that value is in %ENV makes me think it's something else going on, as i'd expect that to be empty as well then.

--
With regards,
Christian Walde
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: PERL5LIB env variable import possibly broken for large contents

> -----Original Message-----
> From: Christian Walde [mailto:mithaldu@yahoo.de]
> Sent: 30 March 2011 10:40
> To: activeperl@listserv.activestate.com; Brian Raven
> Subject: Re: PERL5LIB env variable import possibly broken for large
> contents on Win32? ( Was: Re: Your CPAN smoker is misconfigured? )
>
> On Wed, 30 Mar 2011 11:30:59 +0200, Brian Raven wrote:
>
> >> Of note: The test ( https://gist.github.com/893981#L225 ) clearly
> has a
> >> whole battery of directories in $ENV{PERL5LIB} (
> >> https://gist.github.com/893981#L247 ) which the perl executable can
> >> obviously see, including the Params::Classify dir as the very first;
> >> since that's a Data::Dumper output of %ENV. However @INC remains
> >> unchanged by that. ( https://gist.github.com/893981#L579 )
> >>
> >> This seems to indicate to me that the perl executable itself is, for
> >> whatever reason, flat out ignoring the PERL5LIB and/or failing to
> >> inject it into @INC. Other possibilities include Module::Build
> messing
> >> things up or the Windows Perl executable exclusively having issues.
> >
> > I don't know if this is your problem, but a bit of googling found
> this.
> >
> > http://support.microsoft.com/kb/830473
> >
> > Especially the part about cmd ignoring variables that are longer than
> its limit.
> >
> > HTH
> >
> > P.S. I have not replied to the lists that don't know me from Adam.
>
> At first i thought that was the case too. But the fact that the perl
> executable knows that value is in %ENV makes me think it's something
> else going on, as i'd expect that to be empty as well then.

Maybe so, but spawning a sub process with large environment variables does seem to cause problems. For example, running the following ...

---------------------------------------------------------
use strict;
use warnings;

my $var = "SOMEVAR";
my $check = "check";
my $addthis = "x" x 500;

if (@ARGV > 0) {
if ($ARGV[0] eq $check) {
print "$var is ", length($ENV{$var}), " bytes long\n";
}
else {
print "What '$ARGV[0]'?\n";
}
}
else {
for my $i (1..1000) {
$ENV{$var} .= ";$addthis$i";
system "perl $0 $check";
# system "cmd /c perl $0 $check";
exit if $?;
}
}
---------------------------------------------------------

.... on an XP box, ends as follows...

SOMEVAR is 27153 bytes long
SOMEVAR is 27656 bytes long
SOMEVAR is 28159 bytes long
SOMEVAR is 28662 bytes long
Can't spawn "cmd.exe": No such file or directory at t4.pl line 19.

The contents of PERL5LIB in your link seems to be 46647 bytes long. The link I gave mentions that the win32 limit is 32767. This would suggest that it is unlikely that perl inherited an environment variable that long from its parent process. It seems more likely that perl constructs PERL5LIB, but fails to pass it on to a child process.

Of course, I could be wrong.

HTH


--
Brian Raven






Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PERL5LIB env variable import possibly broken for large contents

On Wed, 30 Mar 2011 10:54:57 +0200, Christian Walde wrote:
> On Wed, 30 Mar 2011 02:22:32 +0200, perl@0ne.us wrote:
>
>> I just got this FAIL report today from CPANTesters:
>>
>> http://www.cpantesters.org/cpan/report/0ee8eb99-6c5d-1014-a6 30-0d8a02da96e1
>>
>> As you can see, the prereq is correctly recognized by the toolchain
>> and loaded - it's even in the lengthy @INC list, BUT when executing the
>> test script it seems like @INC disappears somehow? Since I don't know
>> the details of your setup I have to assume something is broken.
>
> https://gist.github.com/893981
>
> Of note: The test ( https://gist.github.com/893981#L225 ) clearly has a whole battery of directories in $ENV{PERL5LIB} ( https://gist.github.com/893981#L247 ) which the perl executable can obviously see, including the Params::Classify dir as the very first; since that's a Data::Dumper output of %ENV. However @INC remains unchanged by that. ( https://gist.github.com/893981#L579 )
>
> This seems to indicate to me that the perl executable itself is, for whatever reason, flat out ignoring the PERL5LIB and/or failing to inject it into @INC. Other possibilities include Module::Build messing things up or the Windows Perl executable exclusively having issues.

Thanks to Brian Raven i managed to condense this into a minimal test case script and collect behaviors across multiple platforms, so i could figure out that perl core was handling PERL5LIB badly on Windows 7 (ignoring env values despite being able to handle them). I've reported this issue here:

http://rt.perl.org/rt3/Ticket/Display.html?id=87322

As for the smoker, as Lars Dieckow suggests i'll just disable build_dir_reuse for now. It will slow the smoker down massively, but there's no quick fix for this. Maybe sometime in the future i'll build a build_dir_reuse function that can do the same job without increasing ENV vars massively.

Thanks for all the feedback. :)

--
With regards,
Christian Walde
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PERL5LIB env variable import possibly broken for large contents

On Wed, 30 Mar 2011 16:21:36 +0200, Eric Brine wrote:

> Is taint on? Perl ignores PERL5LIB then.

No, not that easy i'm afraid, the issue is different and actually a perl core bug occuring only on Windows 7. I've reported it here: http://rt.perl.org/rt3/Ticket/Display.html?id=87322

--
With regards,
Christian Walde
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PERL5LIB env variable import possibly broken for large contents

On Wed, 30 Mar 2011 18:57:28 +0200, Andreas J. Koenig wrote:

>>>>>> On Wed, 30 Mar 2011 15:42:32 +0200, "Christian Walde" said:
>
> > Maybe sometime in the future i'll build a build_dir_reuse function
> > that can do the same job without increasing ENV vars massively.
>
> Good luck! David and I have tried hard but failed. You find the traces
> of the failed experiment in the repository under CPAN/PERL5INC.pm. I do
> not even remember the details.
>

Thanks. :)

I'll certainly give it a try, since i have an idea that i believe can work. As for PERL5INC, could you be a bit more specific maybe? I checked out the github repo and couldn't find a trace of such a file, nor any branch hinting at it.

--
With regards,
Christian Walde
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: PERL5LIB env variable import possibly broken for large

On Wed, 30 Mar 2011, Brian Raven wrote:
>On Wed, 30 Mar 2011, Christian Walde wrote:
>> At first i thought that was the case too. But the fact that the perl
>> executable knows that value is in %ENV makes me think it's something
>> else going on, as i'd expect that to be empty as well then.
>
> Maybe so, but spawning a sub process with large environment variables
> does seem to cause problems. For example, running the following ...

Yes, that is a limitation of CreateProcessA():

| CreateProcessA fails if the total size of the environment block for
| the process exceeds 32,767 characters.

I've updated Christian's bug report with this information.

Cheers,
-Jan


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PERL5LIB env variable import possibly broken for large contents

On Wed, 30 Mar 2011 21:42:47 +0200, Jan Dubois wrote:

> On Wed, 30 Mar 2011, Brian Raven wrote:
>> On Wed, 30 Mar 2011, Christian Walde wrote:
>>> At first i thought that was the case too. But the fact that the perl
>>> executable knows that value is in %ENV makes me think it's something
>>> else going on, as i'd expect that to be empty as well then.
>>
>> Maybe so, but spawning a sub process with large environment variables
>> does seem to cause problems. For example, running the following ...
>
> Yes, that is a limitation of CreateProcessA():
>
> | CreateProcessA fails if the total size of the environment block for
> | the process exceeds 32,767 characters.
>
> I've updated Christian's bug report with this information.

On Win XP, which Brian's example demonstrates this is correct, however on Windows 7, which is what I'm using, the situation is different. I've updated the bug with a clarification. :)

--
With regards,
Christian Walde
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PERL5LIB env variable import possibly broken for large contents

On Thu, 31 Mar 2011 00:32:12 +0200, Andreas J. Koenig wrote:

>>>>>> On Wed, 30 Mar 2011 19:10:28 +0200, "Christian Walde" said:
>
> > I'll certainly give it a try, since i have an idea that i believe
> > can work. As for PERL5INC, could you be a bit more specific maybe? I
> > checked out the github repo and couldn't find a trace of such a
> > file, nor any branch hinting at it.
>
> I found it again with
>
> git log -p
>
> and then enter: "/CPAN\/PERL5INC" (without the quotes)
>
> commit 327430cd7f57d421a9e4cba1d708fef4c7e14b12 was the one that removed
> the whole idea.
>

Thanks a lot. I really need to learn more about git. :)

And yeah, that is an interesting approach, but i can see how it would be pretty painful to get working reliably.

What i am thinking about is a bit more simplicistic. The sub set_perl5lib is responsible for going through the internal is_tested list and prepending its contents onto PERL5LIB. What i'd change it to is a function that instead creates a temp dir in something like .cpan/build_reuse/******, copies all the blibs and archs into that and then prepends that. It's a bit more work file-system-wise, but it should be pretty reliable.

(Something else i'd like to solve there is a filtering of which of these dists are actually prereqs and which aren't.)

If you have any thoughts on this approach, please let me know. :)

--
With regards,
Christian Walde
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Parsing/interpolation question

I ran into an issue creating hashes with IP addresses as a key. They don't do what you'd expect them to do (at least not what I expected). In other words, $hash{192.168.1.1} isn't the same as $hash{'192.168.1.1'}

I understand what's between the "{" and "}" is subject to interpolation, but I don't understand what perl interpolation rules apply.

What I found is that something like 192.168.1.1 seems to parsed/interpolated as chr(192) . chr(168) . chr(1) . chr(1)

I would have expected that if any interpolation were to be done on 192.168.1.1 the periods would be parsed as a string append giving the result "19216811", which coincidently, is how $x = 192 . 168 . 1 . 1 is parsed.

Is there any documentation of this behavior?



_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Parsing/interpolation question

This is a multi-part message in MIME format.
--===============1919762315==
Content-Type: multipart/alternative;
boundary="--------MB_8CDBDD0506940F0_163C_EC7C_webmail-d033. sysops.aol.com"

This is a multi-part message in MIME format.
----------MB_8CDBDD0506940F0_163C_EC7C_webmail-d033.sysops.a ol.com
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

hi ken --??=20
?
check out the section on 'Version Strings' in perldata.??=20
also -- hash keys are evaluated as expressions and are not=20
subject to string interpolation (unless the expression=20
happens to?contain an interpolable string!).??=20
?
br -- bill??=20




-----Original Message-----
From: Ken Cornetet <Ken.Cornetet@kimball.com>
To: activeperl <activeperl@listserv.activestate.com>
Sent: Thu, Mar 31, 2011 11:05 am
Subject: Parsing/interpolation question




I ran into an issue creating hashes with IP addresses as a key. They don't =
do =20
what you'd expect them to do (at least not what I expected). In other words=
, =20
$hash{192.168.1.1} isn't the same as $hash{'192.168.1.1'}=20
=20
I understand what's between the "{" and "}" is subject to interpolation, bu=
t I =20
don't understand what perl interpolation rules apply.=20
=20
What I found is that something like 192.168.1.1 seems to parsed/interpolate=
d as =20
chr(192) . chr(168) . chr(1) . chr(1)=20
=20
I would have expected that if any interpolation were to be done on 192.168.=
1.1 =20
the periods would be parsed as a string append giving the result "19216811"=
, =20
which coincidently, is how $x =3D 192 . 168 . 1 . 1 is parsed. =20
=20
Is there any documentation of this behavior?=20
=20
=20
=20
_______________________________________________=20
ActivePerl mailing list=20
ActivePerl@listserv.ActiveState.com=20
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs=20
=20


----------MB_8CDBDD0506940F0_163C_EC7C_webmail-d033.sysops.a ol.com
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

I ran into an issue creating hashes with =

IP addresses as a key. They don't do  


what you'd expect them to do (at least not what I expected). In other words=

,  


$hash{192.168.1.1} isn't the same as $hash{'192.168.1.1'} 


 


I understand what's between the "{" and "}" is subject to interpolation, bu=

t I  


don't understand what perl interpolation rules apply. 


 


What I found is that something like 192.168.1.1 seems to parsed/interpolate=

d as  


chr(192) . chr(168) . chr(1) . chr(1) 


 


I would have expected that if any interpolation were to be done on 192.168.=

1.1  


the periods would be parsed as a string append giving the result "19216811"=

,  


which coincidently, is how $x =3D 192 . 168 . 1 . 1 is parsed.  


 


Is there any documentation of this behavior? 


 


 


 


_______________________________________________ 


ActivePerl mailing list 


ActivePerl@listserv.=

ActiveState.com 


To unsubscribe: 
 target=3D_blank>http://listserv.ActiveState.com/mailman/mysu bs 


 

Re: Parsing/interpolation question

Hi,

Ken Cornetet schrieb am Thu, Mar 31, 2011 at 11:04:31AM -0400:

> I ran into an issue creating hashes with IP addresses as a key.
> They don't do what you'd expect them to do (at least not what I
> expected). In other words, $hash{192.168.1.1} isn't the same
> as $hash{'192.168.1.1'}

Right, in this case, the quotes are required.

> I understand what's between the "{" and "}" is subject to
> interpolation,

Not quite, it is interpreted as an expression,
except when it is a bare identifier, see perldata(1),
section DESCRIPTION, subsection "Scalar value constructors":

In fact, an identifier within such curlies is forced to be a string, as
is any simple identifier within a hash subscript. Neither need
quoting. Our earlier example, $days{'Feb'} can be written as
$days{Feb} and the quotes will be assumed automatically. But anything
more complicated in the subscript will be interpreted as an expression.
This means for example that "$version{2.0}++" is equivalent to
"$version{2}++", not to "$version{'2.0'}++".

> but I don't understand what perl interpolation rules apply.
>
> What I found is that something like 192.168.1.1 seems to
> parsed/interpolated as chr(192) . chr(168) . chr(1) . chr(1)

Right, see the same manual page, right afterwards, "Version strings".

A literal of the form "v1.20.300.4000" is parsed as a string composed
of characters with the specified ordinals. This form, known as
v-strings, provides an alternative, more readable way to construct
strings, rather than use the somewhat less readable interpolation form
"\x{1}\x{14}\x{12c}\x{fa0}". This is useful for representing Unicode
strings, and for comparing version "numbers" using the string
comparison operators, "cmp", "gt", "lt" etc. If there are two or more
dots in the literal, the leading "v" may be omitted.

Personally, i consider that a rather ugly feature i'd tend to avoid.

> I would have expected that if any interpolation were to be done
> on 192.168.1.1 the periods would be parsed as a string append giving
> the result "19216811",

This is Perl; the language design is _not_ based on the principle of
least surprise.

> which coincidently, is how $x = 192 . 168 . 1 . 1 is parsed.

Cannot reproduce:

$ perl -Mstrict -we 'my $x = 192.168.1.1; print $x;' \
> | hexdump -e '4/1 " %d"'; echo
192 168 1 1
$ perl --version | head -n2
This is perl 5, version 12, subversion 2 (v5.12.2 (*))
built for i386-openbsd

Yours,
Ingo
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Parsing/interpolation question

"> which coincidently, is how $x = 192 . 168 . 1 . 1 is parsed.
Cannot reproduce"

Because spaces are significant here:

my $x = 192.168.1.1;
# $x is chr(192) . chr(168) . chr(1) . chr(1)
my $y = 192 . 168 . 1 . 1;
# $y is "19216811"

Daniel



From:
Ingo Schwarze
To:
Ken Cornetet
Cc:
activeperl@listserv.activestate.com
Date:
01/04/2011 12:55
Subject:
Re: Parsing/interpolation question
Sent by:
activeperl-bounces@listserv.ActiveState.com



Hi,

Ken Cornetet schrieb am Thu, Mar 31, 2011 at 11:04:31AM -0400:

> I ran into an issue creating hashes with IP addresses as a key.
> They don't do what you'd expect them to do (at least not what I
> expected). In other words, $hash{192.168.1.1} isn't the same
> as $hash{'192.168.1.1'}

Right, in this case, the quotes are required.

> I understand what's between the "{" and "}" is subject to
> interpolation,

Not quite, it is interpreted as an expression,
except when it is a bare identifier, see perldata(1),
section DESCRIPTION, subsection "Scalar value constructors":

In fact, an identifier within such curlies is forced to be a string, as
is any simple identifier within a hash subscript. Neither need
quoting. Our earlier example, $days{'Feb'} can be written as
$days{Feb} and the quotes will be assumed automatically. But anything
more complicated in the subscript will be interpreted as an expression.
This means for example that "$version{2.0}++" is equivalent to
"$version{2}++", not to "$version{'2.0'}++".

> but I don't understand what perl interpolation rules apply.
>
> What I found is that something like 192.168.1.1 seems to
> parsed/interpolated as chr(192) . chr(168) . chr(1) . chr(1)

Right, see the same manual page, right afterwards, "Version strings".

A literal of the form "v1.20.300.4000" is parsed as a string composed
of characters with the specified ordinals. This form, known as
v-strings, provides an alternative, more readable way to construct
strings, rather than use the somewhat less readable interpolation form
"\x{1}\x{14}\x{12c}\x{fa0}". This is useful for representing Unicode
strings, and for comparing version "numbers" using the string
comparison operators, "cmp", "gt", "lt" etc. If there are two or more
dots in the literal, the leading "v" may be omitted.

Personally, i consider that a rather ugly feature i'd tend to avoid.

> I would have expected that if any interpolation were to be done
> on 192.168.1.1 the periods would be parsed as a string append giving
> the result "19216811",

This is Perl; the language design is _not_ based on the principle of
least surprise.

> which coincidently, is how $x = 192 . 168 . 1 . 1 is parsed.

Cannot reproduce:

$ perl -Mstrict -we 'my $x = 192.168.1.1; print $x;' \
> | hexdump -e '4/1 " %d"'; echo
192 168 1 1
$ perl --version | head -n2
This is perl 5, version 12, subversion 2 (v5.12.2 (*))
built for i386-openbsd

Yours,
Ingo
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs