On 4/08/2015 8:33, Mike Flannigan wrote:
On 8/3/2015 9:44 AM, Roderich Schupp wrote:
Good observation! I packed the following script (and checked that it
has Windows CRLF line endings)
--- snip ---
use strict;
use warnings;
use Data::Dumper;
$Data::Dumper::Useqq = 1;
my @data = <DATA>;
print Dumper(\@data);
__DATA__
fooy
bar
quux
--- snip ---
$ perl data.pl <http://data.pl>
$VAR1 = [
"foo\n",
"bar\n",
"quux\n"
];
but when I pack it
$ pp -o data.exe data.pl <http://data.pl>
$ .\data.exe
$VAR1 = [
"foo\r\n",
"bar\r\n",
"quux\r\n"
];
I checked the script as packed into data.exe and it has its CRLF
endings intact.
But the hack that's used to actually run it (i.e. PAR::_run_member)
uses a filehandle opened in binmode.
Looks like the implicit DATA filehandle inherits this setting somehow.
I'll have to think some more whether changing PAR::_run_member might
have side effects.
Cheers, Roderich
Thanks for confirming that. Chomp certainly doesn't fix
the problem. Oddly I couldn't get the variable I wanted
no matter what I did! I always got the variable in front of
or behind the one I wanted, even though I only moved the
array index by one.
I finally gave up and removed all the newlines. I just
put all the data on one line now.
It's a bit frustrating, but I have my fix.
I'm surprised I was the one to point this out.
Must be very few of us Windows par users.
Mike
This is a more general problem than PAR.
I've had similar issues with input files when I was alternating between
cygwin and normal windows in the distant past. Data::Section::Simple
also does the same thing, in that it does not translate crlf endings
when loading from a data block on linux. I expect there are many other
ways of hitting this issue.
The solution I use is to remove the crlf line endings in my code, e.g.:
s/[\r\n]+$// for @data;
or, more verbosely but more clearly:
for my $item (@data) {
$item =~ s/[\r\n]+$//;
}
Regards,
Shawn.
