[32367] in Perl-Users-Digest
Perl-Users Digest, Issue: 3634 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 8 14:09:27 2012
Date: Thu, 8 Mar 2012 11: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 Thu, 8 Mar 2012 Volume: 11 Number: 3634
Today's topics:
Re: Help with dynamic regex <ben@morrow.me.uk>
Re: Help with dynamic regex <rweikusat@mssgmbh.com>
Re: Help with dynamic regex <dave@invalid.invalid>
Re: Help with dynamic regex <jwkrahn@example.com>
Re: Help with dynamic regex <rweikusat@mssgmbh.com>
Re: Help with dynamic regex <rweikusat@mssgmbh.com>
Re: Help with dynamic regex <ben@morrow.me.uk>
Re: Help with dynamic regex <ben@morrow.me.uk>
Re: Help with dynamic regex <dave@invalid.invalid>
if ( -e $file_to_check ) <-- error in AIX 6.1 <rmcgorman@gmail.com>
Re: if ( -e $file_to_check ) <-- error in AIX 6.1 rmcgorman@gmail.com
Re: if ( -e $file_to_check ) <-- error in AIX 6.1 (Tim McDaniel)
Re: little quiz <kiuhnm03.4t.yahoo.it>
Storable.pm failing with error Byte order is not compat <urgearun@gmail.com>
Re: Storable.pm failing with error Byte order is not co <rweikusat@mssgmbh.com>
Re: Storable.pm failing with error Byte order is not co <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 7 Mar 2012 23:44:40 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with dynamic regex
Message-Id: <8g8l29-2dm1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > my $qr = qr/$r/;
> > $s = eval sprintf 'sub { $_[0] =~ s/$qr/XX\1XX/%s; }', $mod;
> >
>
> This is a regex with a variable dynamically interpolated into it, IOW,
> the $qr is evaluated every time the sub is executed, as opposed to
> once when it is compiled. Since this is not good for anything, it
> should rather be avoided.
No it isn't. Run it under re "debug" to see. Since the LHS of the s///
is nothing but a qr//, perl doesn't recompile the regex, it just uses
the compiled version in the qr//. (That's the whole point of qr//.)
In fact, perl is cleverer than that. Even if you were to write
my $r = "f";
$s = eval 'sub { /XX $r/ }';
perl would still only compile the pattern once. It tracks the variables
used by the pattern, and only recompiles it if they've changed. (This is
why /o is not useful any more.)
Your code,
$s = eval(sprintf('sub { $_[0] =~ s/(%s)/XX\1XX/%s; }',
qr/$r/, $mod));
OTOH, compiles the pattern twice. First it is compiled into a qr//, then
that qr// is stringified and interpolated into a larger string, then
that larger string is evaled. The eval will have to compile the pattern
again, since it's lost any connection to the first qr//.
> > I might even consider that safe enough to use, given that the
> > interpolated section is now entirely predictable, except that there's no
> > need for eval at all. The only modifers you are accounting for that
> > can't be put in a (?X) are /g and /o, and /o isn't useful anyway, so
> > there's really nothing wrong with
> >
> > my $g = $mod =~ s/g//g;
> > if ($g) {
> > $a =~ s/(?$mod)$r/XX$1XX/g;
> > }
> > else {
> > $a =~ s/(?$mod)$r/XX$1XX/;
> > }
> >
> > and it's a whole lot harder to get wrong.
>
> It is more code (consequently, it is easier to get wrong) and it
> requires a conditional test whose outcome is always either one way or
> the other way for each line of input processed. And log files can
> easily be huge. Not to mention that it is also prone to so-called
> 'update anomalies' since there are now two replacement expressions
> which need to be kept in sync manually.
I'd rather risk a mistake which produced an easily-visible incorrect
result than a mistake which produced a security hole. Yes, I agree,
doing things the long way round is inconvenient, but eval is just too
easy to get wrong.
> There's no problem with eval per se, just with the string which is
> actually evaluated. Consequently, there is some (possibly absent)
> input validation/ sanitization code and this code can either be
> correct, then, evaluating the input is 'safe;', or incorrect and then, it
> isn't provided 'evaluating user input' isn't intentionally done in
> order to enable users to execute whatever Perl code might be useful
> for them.
Yes, for those of us who are perfect programmers (and who can be certain
everyone maintaining the code after them will be too), eval can be
terribly convenient. For those of us who live in the real world, it
isn't safe.
> I've done this at least once in the past, with a script
> which was not intended to be a security boundary,
A CGI script (or anything else which talks to the network) should always
be considered a security boundary. That's part of my point.
Ben
------------------------------
Date: Thu, 08 Mar 2012 00:15:39 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Help with dynamic regex
Message-Id: <87eht46j84.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > my $qr = qr/$r/;
>> > $s = eval sprintf 'sub { $_[0] =~ s/$qr/XX\1XX/%s; }', $mod;
>> >
>>
>> This is a regex with a variable dynamically interpolated into it, IOW,
>> the $qr is evaluated every time the sub is executed, as opposed to
>> once when it is compiled. Since this is not good for anything, it
>> should rather be avoided.
>
> No it isn't. Run it under re "debug" to see. Since the LHS of the s///
> is nothing but a qr//, perl doesn't recompile the regex, it just uses
> the compiled version in the qr//. (That's the whole point of qr//.)
>
> In fact, perl is cleverer than that. Even if you were to write
>
> my $r = "f";
> $s = eval 'sub { /XX $r/ }';
>
> perl would still only compile the pattern once. It tracks the variables
> used by the pattern, and only recompiles it if they've changed. (This is
> why /o is not useful any more.)
The most-recent perl I'm using is 5.10.1 and it still documents this
as
PATTERN may contain variables, which will be interpolated (and
the pattern recompiled) every time the pattern search is
evaluated, except for when the delimiter is a single quote.
(Note that $(, $), and $| are not interpolated because they
look like end-of-string tests.) If you want such a pattern to
be compiled only once, add a "/o" after the trailing
delimiter.
Even assuming the additional checks you mentioned above (since when to
these exist), that still means execution-time overhead which can
easily be avoided.
> Your code,
>
> $s = eval(sprintf('sub { $_[0] =~ s/(%s)/XX\1XX/%s; }',
> qr/$r/, $mod));
>
> OTOH, compiles the pattern twice. First it is compiled into a qr//, then
> that qr// is stringified and interpolated into a larger string, then
> that larger string is evaled. The eval will have to compile the pattern
> again, since it's lost any connection to the first qr//.
Well, yes. But since this is executed only once while the substitution
routine is possibly called millions (if not billions) of times, that
seems like a worthwhile tradeoff to me.
[...]
>> There's no problem with eval per se, just with the string which is
>> actually evaluated. Consequently, there is some (possibly absent)
>> input validation/ sanitization code and this code can either be
>> correct, then, evaluating the input is 'safe;', or incorrect and then, it
>> isn't provided 'evaluating user input' isn't intentionally done in
>> order to enable users to execute whatever Perl code might be useful
>> for them.
>
> Yes, for those of us who are perfect programmers (and who can be certain
> everyone maintaining the code after them will be too), eval can be
> terribly convenient. For those of us who live in the real world, it
> isn't safe.
"It isn't safe" means nothing except "Be afraid of it! You really
ought to!". Nothing which can be misused is safe from being misused
and 'in the real world' people who are anything but 'perfect
programmers' have created a whole new class of exploits by
interpolating userdata into SQL statement templates without proper
quoting (so-called 'SQL injection'). And the solution to this problem
is not 'trying to scare people away from using this technique' (that's
not going to work for the people who created the problem, anyway,
because their main objective is usually "get shit done fast") but to
teach them how to avoid interpolation into strings when it isn't
needed (eg, when a parametrized query can be used instead) and how to
do it safely when it is needed.
Granted, it would be nicer when Perl had some structured
representation of its own code which could be used for runtime code
generation but that gets us deeply into 'oatmeal with finger nail
clippings' territory :-) (and IMHO, the lisp guys went off the deep end
with CLOS ...).
>> I've done this at least once in the past, with a script
>> which was not intended to be a security boundary,
>
> A CGI script (or anything else which talks to the network) should always
> be considered a security boundary. That's part of my point.
And this point is wrong: Eg, a CGI script which is supposed to be used
by authenticated users to make configuration changes to some system
they control is not a security boundary.
------------------------------
Date: Thu, 8 Mar 2012 08:59:53 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with dynamic regex
Message-Id: <fV45K0OBJxbE-pn2-pYSpehMOW3ww@localhost>
On Wed, 7 Mar 2012 20:20:09 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "Dave Saville" <dave@invalid.invalid>:
> > On Wed, 7 Mar 2012 17:54:28 UTC, Rainer Weikusat
> > <rweikusat@mssgmbh.com> wrote:
> > > Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> > >
> > > > if ($r =~ /(.)(.*)\1([giomsx]*)$/) {
> > > > $s = eval(sprintf('sub { $_[0] =~ s/(%s)/XX\1XX/%s; }',
> > > > $2, $3));
> > >
> > > Additional remark: Because this is based on interpolating a string
> > > into some code,
>
> ...it is a completely stupid thing to do in a CGI script. This is,
> unforunately, a case which would have slipped by taint mode, but it's
> still ridiculously dangerous.
>
So given the original problem - Search remote log files for some
arbitary regex - how would you go about it? SSH to the box and grep is
not an acceptable solution. Much easier in a browser where the log
files are predefined ( one does not have to remember *where* they are
- not all in /var/log) and additionally you have the browsers search
and highlight to play with.
> > > it will be possible to use this to execute arbitrary
> > > code by providing suitable input to the script, eg,
> > >
> > > my $r = '|a)//; print "Gotcha!\n"; s/(b|';
> > >
> > > will print Gotcha! whenever the substituation routine is
> > > executed. OTOH, since regexes support executing code anyway, this
> > > might not be much of a concern.
>
> Regexes are protected against interpolated sections containing (?{}) and
> the like. See the documentation for 'use re "eval"'.
>
> > No concern at all in this case as it's just me. :-)
>
> That is the *wrong* attitude. If it's a CGI script you *must* assume Bad
> People will get their hands on it, no matter how 'internal' you think
> the webserver serving it is. You should be using taint mode and writing
> with security in mind.
>
Given that it is my system and that particular script is on a non
standard port that is shut on the firewall I think that is very
internal :-) My server *always* runs taint mode *and* I check the
logs.
As a general point, if you need to provide a search to end users,
forgeting my requirement to type a regex, how would you sanitise the
provided search? ie just a simple string search but that would be
implemented by a regex.
--
Regards
Dave Saville
------------------------------
Date: Thu, 08 Mar 2012 03:51:56 -0800
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: Help with dynamic regex
Message-Id: <w316r.1790$v11.910@newsfe20.iad>
Ben Morrow wrote:
>
> Quoth Rainer Weikusat<rweikusat@mssgmbh.com>:
>>
>> my $r = '/g/g';
>> my ($s, $mod);
>>
>> if ($r) {
>> if ($r =~ /(.)(.*)\1([giomsx]*)$/) {
>> $r = $2;
>> $mod = $3;
>> }
>>
>> $s = eval(sprintf('sub { $_[0] =~ s/(%s)/XX\1XX/%s; }',
>> qr/$r/, $mod));
>
> Clever. Of course, eval is lexically scoped within the surrounding
> block, so there's no need to compile the regex twice:
>
> my $qr = qr/$r/;
> $s = eval sprintf 'sub { $_[0] =~ s/$qr/XX\1XX/%s; }', $mod;
You are still compiling the regexp twice. Also there is no need to use
sprintf and the use of \1 in the replacement string should be $1:
$s = eval "sub { \$_[0] =~ s/$r/XX\${1}XX/$mod; }";
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Thu, 08 Mar 2012 15:09:49 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Help with dynamic regex
Message-Id: <87eht3ruwy.fsf@sapphire.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
> On Wed, 7 Mar 2012 20:20:09 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
[...]
> As a general point, if you need to provide a search to end users,
> forgeting my requirement to type a regex, how would you sanitise the
> provided search? ie just a simple string search but that would be
> implemented by a regex.
Use qr//, cf
This operator quotes (and possibly compiles) its STRING
as a regular expression. STRING is interpolated the
same way as PATTERN in "m/PATTERN/". If "'" is used as
the delimiter, no interpolation is done.
The qr actually means 'quote regex' and judging from the 'and possibly
compiles' quoted above, it was originally meant to be used for
quoting.
------------------------------
Date: Thu, 08 Mar 2012 15:46:07 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Help with dynamic regex
Message-Id: <87aa3rrt8g.fsf@sapphire.mobileactivedefense.com>
"John W. Krahn" <jwkrahn@example.com> writes:
> Ben Morrow wrote:
[...]
>> $s = eval sprintf 'sub { $_[0] =~ s/$qr/XX\1XX/%s; }', $mod;
>
> You are still compiling the regexp twice. Also there is no need to
> use sprintf and the use of \1 in the replacement string should be $1:
>
> $s = eval "sub { \$_[0] =~ s/$r/XX\${1}XX/$mod; }";
The \1 on the RHS came from the originally posted code. According to
perlre(1),
This is grandfathered for the RHS of a substitute to avoid
shocking the sed addicts, but it's a dirty habit to get into.
So, if somebody wants to use it in his own code, why not? The sprintf
came from me. I usually prefer that to doing variable interpolations
because it clearly separates the template string and the argument
interpolated into it.
------------------------------
Date: Thu, 8 Mar 2012 15:39:45 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with dynamic regex
Message-Id: <1f0n29-r6c2.ln1@anubis.morrow.me.uk>
Quoth jwkrahn@shaw.ca:
> Ben Morrow wrote:
> > Quoth Rainer Weikusat<rweikusat@mssgmbh.com>:
> >
> > Clever. Of course, eval is lexically scoped within the surrounding
> > block, so there's no need to compile the regex twice:
> >
> > my $qr = qr/$r/;
> > $s = eval sprintf 'sub { $_[0] =~ s/$qr/XX\1XX/%s; }', $mod;
>
> You are still compiling the regexp twice.
No I'm not. Run it under re "debug". As I said to Rainer, there wouldn't
be much point to qr// otherwise.
> Also there is no need to use
> sprintf and the use of \1 in the replacement string should be $1:
>
> $s = eval "sub { \$_[0] =~ s/$r/XX\${1}XX/$mod; }";
I agree about \1 (that was from the code I was modifying) but the
sprintf isn't doing quite what you think. That format string is
single-quoted, so $qr is closed over rather than interpolated. I could
have written
$s = eval "sub { \$_[0] =~ s/\$qr/XX\${1}XX/$mod; }';
but tbh sprintf seems preferable to all those backslashes.
Ben
------------------------------
Date: Thu, 8 Mar 2012 16:08:21 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with dynamic regex
Message-Id: <l42n29-hsc2.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Wed, 7 Mar 2012 20:20:09 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Dave Saville" <dave@invalid.invalid>:
> > > On Wed, 7 Mar 2012 17:54:28 UTC, Rainer Weikusat
> > > <rweikusat@mssgmbh.com> wrote:
> > > > Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> > > >
> > > > > if ($r =~ /(.)(.*)\1([giomsx]*)$/) {
> > > > > $s = eval(sprintf('sub { $_[0] =~ s/(%s)/XX\1XX/%s; }',
> > > > > $2, $3));
> > > >
> > > > Additional remark: Because this is based on interpolating a string
> > > > into some code,
> >
> > ...it is a completely stupid thing to do in a CGI script. This is,
> > unforunately, a case which would have slipped by taint mode, but it's
> > still ridiculously dangerous.
>
> So given the original problem - Search remote log files for some
> arbitary regex - how would you go about it? SSH to the box and grep is
> not an acceptable solution.
I posted a solution: do as you were doing before, converting the
modifiers into a (?X) expression, but handle /g separately with a
full-blown if/else. In principle it's cleaner to decompose s/// into its
constituent operations, something like this:
sub subst {
my ($targ, $rx, $fl, $g, $repl) = @_;
while ($$targ = /(?$fl)$rx/g) {
my ($start, $len) = ($-[0], $+[0] - $-[0]);
my $r = sprintf $repl, substr $$targ, $start, $len;
substr $$targ, $start, $len, $r;
pos($$targ) = $start + length $r;
$g or last;
}
}
my $x = "foo fooo Foo";
subst $x, "fo*", "i", 1, "XX%sXX";
but I probably wouldn't bother.
> As a general point, if you need to provide a search to end users,
> forgeting my requirement to type a regex, how would you sanitise the
> provided search? ie just a simple string search but that would be
> implemented by a regex.
/\Q$str/
Ben
------------------------------
Date: Thu, 8 Mar 2012 17:23:19 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with dynamic regex
Message-Id: <fV45K0OBJxbE-pn2-cdi3nWc4htgh@localhost>
Thanks Ben and Rainer for your help and explanations. Working to my
satisfaction now :-)
--
Regards
Dave Saville
------------------------------
Date: Thu, 8 Mar 2012 05:58:47 -0800 (PST)
From: Richard <rmcgorman@gmail.com>
Subject: if ( -e $file_to_check ) <-- error in AIX 6.1
Message-Id: <e1d9a65c-09a0-4457-9a36-ccfa92148921@w5g2000vbv.googlegroups.com>
We're seeing different behaviour with our Perl scripts after upgrading
from AIX 5.3 to AIX 6.1. Here's a example that shows the issue:
#!/usr/bin/perl -w
use File::Find;
use File::Basename;
$file_to_check = " ";
if ( -e $file_to_check ) {
print "File found\n";
}
else {
print "No file found\n";
}
When I run this under AIX 5.3 I get
No file found
But under AIX 6.1 I get
File found
In our actual code the filename is passed to the script. Sometimes
it's blank. In AIX 6.1 it says the file is found even though it's a
blank filename.
This is the perl version string from both AIX 5.3 and 6.1
This is perl, v5.8.8 built for aix-thread-multi
While we could change our code to deal with this, it seems like it's
not working correctly under AIX 6.1.
Anyone else on AIX 6.1 that can verify the behaviour?
Thanks for any help.
Richard
------------------------------
Date: Thu, 8 Mar 2012 07:35:13 -0800 (PST)
From: rmcgorman@gmail.com
Subject: Re: if ( -e $file_to_check ) <-- error in AIX 6.1
Message-Id: <28175993.99.1331220913805.JavaMail.geo-discussion-forums@vbcv2>
Nevermind. It turns out we had a file that had a blank filename in the directory where we are running the perl.
There must be a good reason to allow it, but having Unix allow a filename that's blank seems bizarre, and can lead to confusing situation like this one.
On Thursday, March 8, 2012 8:58:47 AM UTC-5, Richard wrote:
> We're seeing different behaviour with our Perl scripts after upgrading
> from AIX 5.3 to AIX 6.1. Here's a example that shows the issue:
>
> #!/usr/bin/perl -w
>
> use File::Find;
> use File::Basename;
>
>
> $file_to_check = " ";
> if ( -e $file_to_check ) {
> print "File found\n";
> }
> else {
> print "No file found\n";
> }
>
>
> When I run this under AIX 5.3 I get
>
> No file found
>
> But under AIX 6.1 I get
>
> File found
>
>
> In our actual code the filename is passed to the script. Sometimes
> it's blank. In AIX 6.1 it says the file is found even though it's a
> blank filename.
>
> This is the perl version string from both AIX 5.3 and 6.1
>
> This is perl, v5.8.8 built for aix-thread-multi
>
>
> While we could change our code to deal with this, it seems like it's
> not working correctly under AIX 6.1.
>
> Anyone else on AIX 6.1 that can verify the behaviour?
>
> Thanks for any help.
>
> Richard
------------------------------
Date: Thu, 8 Mar 2012 16:35:30 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: if ( -e $file_to_check ) <-- error in AIX 6.1
Message-Id: <jjan4i$s1d$1@reader1.panix.com>
In article
<28175993.99.1331220913805.JavaMail.geo-discussion-forums@vbcv2>,
<rmcgorman@gmail.com> wrote:
>There must be a good reason to allow it, but having Unix allow a
>filename that's blank seems bizarre, and can lead to confusing
>situation like this one.
Speaking broadly, UNIXY systems tend to be permissive instead of
enforcing what the developers think is reasonable, the which notions
often enough do not match my own notions of reasonable.
Or, more briefly, UNIXy systems are X-Acto(TM) knives, not kiddie
scissors.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 08 Mar 2012 19:51:09 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: little quiz
Message-Id: <4f58ff9b$0$1381$4fafbaef@reader2.news.tin.it>
On 3/7/2012 12:15, Shmuel (Seymour J.) Metz wrote:
> In<4f56a849$0$1383$4fafbaef@reader2.news.tin.it>, on 03/07/2012
> at 01:14 AM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>
>> It goes without saying that I was talking of Perl.
>
> No. You were responding to Ben Morrow's "Having global subs is a
> feature, not a bug. Having *only* global subs is a bug; AIUI Perl 6
> has proper lexically-scoped named subs." If you were talking of Perl
> then you were engaging in circular reasoning; it's not a bug because
> that's how it is. "But named sub are always global." was not
> responsive to his comment if you were talking only about Perl.
My reply wasn't
"But named sub[s] are always global."
It was
"But named sub[s] are always global. Why should I use a coderef just
to make a sub non-global?"
What does that question imply? It implies that I was lamenting the fact
that, *IN PERL*, NAMED subs are always global. Does that imply that I
thought that named subs were always global in general? I honestly don't
think so.
You say "it's not a bug because that's how it is". I disagree. Ben
Morrow and I were talking of design bugs. I would've used the term
"flaw" but Ben Morrow's English is certainly better than mine so I
accepted his terminology.
Kiuhnm
------------------------------
Date: Thu, 8 Mar 2012 07:21:30 -0800 (PST)
From: arun <urgearun@gmail.com>
Subject: Storable.pm failing with error Byte order is not compatible at blib/lib/Storable.pm
Message-Id: <5808013a-eb34-4f87-8419-dfd3f354c31f@ni10g2000pbc.googlegroups.com>
I recently migrated the perl code from SunSolaris to a linux box of
64 bit .
After the migration Storable.pm is breaking with the following error.
Could you please help me in resolving this.
Error:
Byte order is not compatible at blib/lib/Storable.pm (autosplit into
blib/lib/auto/Storable/_retrieve.al) line 324, at testStorable.pl line
15
Code:
#!/usr/local/bin/perl5.6
use strict;
use Data::Dumper; $Data::Dumper::Indent = 1;
use Storable;
$Storable::interwork_56_64bit = 1;
my $gNgrpReleaseGraphFile = "usr/local/GRAPH_data";
my $graph = retrieve( $gNgrpReleaseGraphFile );
print Data::Dumper($graph);
Appreciate your response.
------------------------------
Date: Thu, 08 Mar 2012 16:18:00 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Storable.pm failing with error Byte order is not compatible at blib/lib/Storable.pm
Message-Id: <871up3rrrb.fsf@sapphire.mobileactivedefense.com>
arun <urgearun@gmail.com> writes:
> I recently migrated the perl code from SunSolaris to a linux box of
> 64 bit .
> After the migration Storable.pm is breaking with the following error.
>
> Could you please help me in resolving this.
>
> Error:
> Byte order is not compatible at blib/lib/Storable.pm (autosplit into
> blib/lib/auto/Storable/_retrieve.al) line 324, at testStorable.pl line
> 15
>
> Code:
> #!/usr/local/bin/perl5.6
>
> use strict;
> use Data::Dumper; $Data::Dumper::Indent = 1;
> use Storable;
>
> $Storable::interwork_56_64bit = 1;
>
> my $gNgrpReleaseGraphFile = "usr/local/GRAPH_data";
>
> my $graph = retrieve( $gNgrpReleaseGraphFile );
> print Data::Dumper($graph);
>
> Appreciate your response.
Was the file created on a SPARC machine running Solaris? If so, the
byte order is not compatible (to Linux on X86*) because SPARC is
big-endian and x86 little-endian. That's not related to the '64 bit
data in perl 5.6.0 and 5.6.1' section of the man page despite that
contains the same error message. You will need to recreate the file on
the big-endian box using 'Network order' (that is, writing it in
big-endian and recording 'network [byte] order' in the header) in
order to be able to read it on the Linux box. It may also be possible
to just change the header of the file if the Storable 'network byte
order' serialization isn't really different from a native big-endian
one.
------------------------------
Date: Thu, 8 Mar 2012 16:15:00 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Storable.pm failing with error Byte order is not compatible at blib/lib/Storable.pm
Message-Id: <4h2n29-hsc2.ln1@anubis.morrow.me.uk>
Quoth arun <urgearun@gmail.com>:
> I recently migrated the perl code from SunSolaris to a linux box of
> 64 bit .
> After the migration Storable.pm is breaking with the following error.
>
> Could you please help me in resolving this.
>
> Error:
> Byte order is not compatible at blib/lib/Storable.pm (autosplit into
> blib/lib/auto/Storable/_retrieve.al) line 324, at testStorable.pl line
> 15
Sparc boxes use big-endian byte order, AMD64 boxes use little-endian.
You need to go back to your Sparc box and re-Store everything using
'nstore' instead of 'store'. I don't think there's any way to retreive a
'store'd file on the wrong architecture (except by using an emulator).
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 3634
***************************************
