Where does pp (PAR) unpack add (-a) files?

Question

This is my attempt to cut through extraneous issues raised "Why don’t my system calls work in the Perl program I wrap with pp?" I have created a simple Perl script on a linux system:

new-net:~/scripts # cat ls_test.pl
@ls_out = `ls -l`;

map { print "$_\n" } @ls_out;

$out = `sh out_test.sh`;

print "$out\n";

This script calls a simple shell file:

new-net:~/scripts # cat out_test.sh
echo "I'm here"

I used pp to pack the Perl script along with the shell script into ls_test:

new-net:~/test # unzip -l ls_test
Archive:  ls_test
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  07-13-09 16:41   script/
      436  07-13-09 16:41   MANIFEST
      214  07-13-09 16:41   META.yml
       93  07-13-09 16:41   script/ls_test.pl
      538  07-13-09 16:41   script/main.pl
       16  07-13-09 16:20   out_test.sh
 --------                   -------
     1297                   6 files

If I run the packed file in an otherwise empty directory, the shell script is not found:

new-net:~/test # ./ls_test
total 3391

-rwxr-xr-x 1 root root 3466177 Jul 13 16:41 ls_test

sh: out_test.sh: No such file or directory

If I copy the shell script into the directory, the packed script runs as expected:

new-net:~/test # ./ls_test

total 3395

-rwxr-xr-x 1 root root 3466177 Jul 13 16:41 ls_test
-rw-r--r-- 1 root root      16 Jul 13 16:20 out_test.sh

I'm here

So, where does a pp packed script expect to find an included file? And how should a call to that included file be configured in the original Perl script?

Skeleton

Answer 1

The files in a packaged executable are extracted to a temporary directory (usually /tmp/par-USERNAME/cache-XXXXXXX). To access these files do something like the following:

#!/usr/bin/perl

# Reads a data file from the archive (added with -a)
print PAR::read_file("data");

# Will execute "script2" in the archive and exit. Will not return to this script.
require PAR;
PAR->import( { file => $0, run => 'script2' } );

You can also make symolic links to the executable that have the same name as the script you want to run, and run those.

Actually, rereading your question, simply accessing the PAR_TEMP environment variable is probably more useful:

#!/usr/bin/perl
use File::Slurp qw(slurp);

$data_dir = "$ENV{PAR_TEMP}/inc";
$script_dir = "$data_dir/script";

print slurp("$data_dir/datafile");

# file access permissions are not preserved as far as I can tell,
# so you'll have to invoke the interpreter explicitly.
system 'perl', "$script_dir/script2", @args;

Praxis

from perldoc PAR; run The name of a script to run in the par. Exits when done. Does this mean that any call to an added file exits the packaged script? The problem I was originally trying to solve is a POE/TK script that calls various external files from widget commands. – Skeleton

Answer 2

Thanks to everyone for contributing to this answer. I am adding this answer to distill out the parts of everyone's invaluable input that I used to come up with the solution that worked for me in my particular application.

The app is written in ActiveState Perl using POE and Tk and packaged for distribution using pp. It makes use of several external files; some for input into the program (munged data from DNS) and some for actions taken by the user (creation and deletion of DNS alias records).

The PAR packer (pp) includes external files using the -a argument. These files are unpacked into the \inc directory under a "temp" path created by the package and available to the script via

$ENV{PAR_TEMP}

The first step in the solution was to add this information to the POE "$heap". The line below is in the in-line state "_start";

$heap->{t_path} = "$ENV{PAR_TEMP}\\inc\\";

As I am working in the Win32 environment, I used the escaped backslashes to append the \inc directory into the temp path.

When calling an external file for input into the application, I used a variable (@zone) to return the data;

@zone = `$heap->{t_path}dnscmd aus-dc1 /enumrecords company.pvt @`;

For calls to complete external actions, the files are called without saving the output;

`$heap->{t_path}cpau -dec -file $heap->{t_path}del_event.job -nowarn -wait`;

Thanks again to everyone for contributing and thanks to stackoverflow for providing this great environment.

Skeleton

use File::Spec->catfile( $ENV{PAR_TEMP}, 'inc') rather than messing with double backslashes. By the way, I am a little surprised that I am the only one who has upvoted any answers in this thread: The way you show appreciation on SO is by upvoting answers. – Istle

Answer 3

Here is something that worked on my system:

C:\tmp> cat build.bat
@echo off
mkdir output
call pp -o runner.exe runner.pl -a sayhello.bat
move runner.exe output\runner.exe

C:\tmp> cat sayhello.bat
@echo I am saying hello ...

C:\tmp> cat runner.pl
#!/usr/bin/perl

use strict;
use warnings;

use File::Spec::Functions qw( catfile );

my $prog_path = catfile $ENV{PAR_TEMP}, inc => 'sayhello.bat';

my $output = `$prog_path`;

print "The output was: >>> $output <<< ";

__END__

Output:

C:\tmp\output> runner.exe
The output was: >>> I am saying hello ...
<<<

This feels a little dirty, though.

Solicit

Looks like on MSWindows the default cache/temp directory for PAR is the current directory. – Praxis

Nope, C:\DOCUME~1\username\LOCALS~1\Temp\par-username\cache-07b6bc6c42c824d8fdd5abd08eb8b67b2bf7ecab ... However, your comment made me realize that I had forgotten to fix the build.bat in the post. – Istle

Using PAR_TEMP is dirty? I haven't found any other means to refer to the extraction directory. You can of course extract the archive yourself, then you know where it is. – Praxis

Not is ... feels ... a little ... Anyway, given that I did not have any luck with fsutil hardlink create, this seems to be only option. – Istle

I can see that using PAR_TEMP may be a little dirty because it isn't mentioned in either the manpage of PAR or the one of pp. But I doubt it'll go away since it's convenient to have. – Praxis