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?

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;

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.