I'm running into a problem with the 'do' function in a packed
application on Windows using perl 5.8.8 and the latest par-packer. As
long as the file name I pass to 'do' is an absolute path, everything
works as expected. However, if I pass a relative path, the script fails
if it is running in a packed application.
Here is a test case that demonstrates the problem.
my ($name) = @ARGV;
if (!(do $name)) {
die "failed \...@=$@ \$!=$! \n";
}
exit 1;
Pack the program:
pp.bat myprog.pl -o myprog.exe
Create a test script 'sub/junk.pl':
print "in sub/junk.pl"
exit 0
Run the program stand alone:
$ perl myprog.pl sub/junk.pl
in sub/junk.pl
$ echo $?
0
Run the packed application
$ myprog.exe sub/junk.pl
failed $...@= $!=No such file or directory
$ echo $?
2
I've traced through the par code and as far as I can tell by the time
the myprog.pl script is invoked, the working directory as given to the
perl script is correct. If I exec a subprocess, to display the contents
of the current directory, everything seems ok. It only seems to be a
problem with 'do'. My suspicion is that the static perl process has the
PAR_TEMP directory as the global process working directory and that 'do'
is using that value for file look ups instead of the interpreter's
notion of the current working directory, however I haven't been able to
confirm this yet.
First of all, can anyone else confirm the existence of the problem, and
second does anyone have a proposal for how to fix this? Obviously I can
work around it by converting my file names to absolute paths before
calling 'do', but this is an annoying difference between packed and
unpacked behavior.
--Scott
