Sat Nov 03 10:57:59 2018: Request 127538 was acted upon.
Transaction: Correspondence added by RSCHUPP
       Queue: PAR-Packer
     Subject: __DATA__ file handle not available when Filter(s) used 
   Broken in: (no value)
    Severity: (no value)
       Owner: Nobody
  Requestors: don.peddic...@navy.mil
      Status: new
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=127538 >


On 2018-10-31 12:51:13, don.peddic...@navy.mil wrote:
> ---------  perl code --

Hi Don,

I checked how PAR::Filter::Bleach transforms you script when it gets
packed and the resulting file looks OK (esp. __DATA__ hasn't been stripped).
The problem appears to be caused by Perl itself. 
Try the following script (this is essentially how PAR::Filter::Bleach works):

----- snip -----
$_=<<'...'; print "---\n$_---\n"; eval $_;
use strict;
use warnings;
print "DATA start\n";
foreach (<DATA>) {
 print "data: $_ \n";
}
print "DATA end\n";
1;

__DATA__
This is line one
This is line two
...
----- snip -----

Running this I get:


---
use strict;
use warnings;
print "DATA start\n";
foreach (<DATA>) {
 print "data: $_ \n";
}
print "DATA end\n";
1;

__DATA__
This is line one
This is line two
---
DATA start
readline() on unopened filehandle DATA at (eval 1) line 4.
DATA end


So "eval STRING;" somehow ignores __DATA__ content in STRING.
PAR::Filter::Crypto is implemented differently: it's a source filter
(cf. "perldoc perlfilter", esp. "THINGS TO LOOK OUT FOR"), 
but source filters also interact badly with __DATA__:

----- snip -----
use Filter::exec qw( cat );
use strict;
use warnings;
print "DATA start\n";
foreach (<DATA>) {
 print "data: $_ \n";
}
print "DATA end\n";
1;

__DATA__
This is line one
This is line two
----- snip -----

Running it produces:

DATA start
DATA end


So, in short, packing scripts that use __DATA__ with-f/-F won't work
and there's nothing PAR::Packer can do about it.

Cheers, Roderich
  • [rt.cpan.org #... Peddicord, Don D JR CIV SPAWARSYSCEN-ATLANTIC, 59440 via RT
    • [rt.cpan.... Roderich Schupp via RT
    • [rt.cpan.... Roderich Schupp via RT

Reply via email to