Consider the following code:


perlapp.exe  --bind gpl.txt[file=C:\Src\gpl.txt,text,extract,mode=666] 
--norunlib Test.pl

## BEGIN CODE (test.pl)
use strict;

print "hi\n";

my $datafile = "gpl.txt";
my $filename = PerlApp::extract_bound_file($datafile);
die "$datafile not bound to application\n" unless defined $filename;
print "\n$filename\n";
print "Go check your temp directory and then type [ENTER] to finish\n";
my $in = <STDIN> ;

## END

This will hold the application open while you look in your temp directory.
According to the documentation in the PDK, the bound file is destroyed 
after the script exits.


Bullock, Howard A. wrote:

> Code Correction. itotest-perlapp.opt below was corrected bind statements
> referenced wrong files. I apologize for constructing the email during the
> debugging session and prior to the finalization test code. 
> 
> TEST #1
> Script(itotest.pl):
> 
> use strict;
> print "hi\n";
> 
> Options file(itotest-perlapp.opt):
> 
> --verbose
> --force
> --bind notepad.exe[file=c:\winnt\system32\notepad.exe,extract]
> --bind junk.pl[file=c:\data\scripts\junk.pl,text,0777]
> 
> Compile:
> 
> perlapp.exe @itotest-perlapp.opt itotest.pl
> 
> 
> My understanding is that without the -clean option is NOT used and the
> "extract" option is used on the "bind" line a directory (PDK-userID) should
> be created in the user's %temp% directory.  In this directory the binary of
> "notepad.exe" should be extracted to this directory.
> 
> When I inspect the directory (%temp%) this directory is not created and no
> extracted file exists.
> 
> 
> TEST #2
> 
> When I add the following lines to the script and recompile.
> 
> my $name = PerlApp::extract_bound_file('notepad.exe');
> print "File: $name  extracted\n";
> 
> $name = "C:\DOCUME~1\adminhab\LOCALS~1\Temp\pdk-AdminHAB-2748/notepad.exe"
> 
> This seems quite strange as -clean was not specified in the compile so no
> PID should be used in the directory name. Regardless the return value from
> PerlApp::extract_bound_file seems to be useless as it does not seem to
> related to the physical names on disk.
> 
> This path is unusable as the two files created are:
> 48bcd8db11bf5e4f21d5560dd4ab04af.dll
> a6eeba928fb0e88bf214579ea961eea5.dll
> 
> I think my PDK build 530 behaves the same way, but I have not had a need to
> recompile this program since PDK 4.0.
> 
> Is this expected behavior? Is there a way to bind a file (Zip) and then
> extract it again to the original filename?
> 
> Howard A. Bullock
> Computer Security
> 717-810-3584
> 
> 
> _______________________________________________
> PDK-Beta@[...].com
> http://listserv.ActiveState.com/mailman/listinfo/pdk-beta
> _______________________________________________
> PDK-Beta@[...].com
> http://listserv.ActiveState.com/mailman/listinfo/pdk-beta
>   
>