Re: [PDK-Beta] PerlApp extract bound file problem
by Michael Nacey other posts by this author
Oct 12 2004 1:34PM messages near this date
view in the new Beta List Site
RE: [PDK-Beta] PerlApp extract bound file problem
|
Re: [PDK-Beta] PerlApp extract bound file problem
I believe that the "object files" it refers to are the extracted modules
and runtime files, rather than manually bound file(s).
If I recall, Perlapp used to extract the modules to the temp directory
into separate folders, but it does not appear to do so now (at least I
cannot find them). An old script I had that used TK would create a
directory structure inside the temp folder that contained a Tk folder,
an Auto folder, the Perl56.dll, and the PerlApp.dll. I believe this is
what the "-clean" is referring to.
Bullock, Howard A. wrote:
> Thanks for the reply. You have opened my eyes a little wider. I am still not
> sure why the bound files are extracted into a different subdirectory using
> the PID in the directory name. The docs led me to believe that if the
> "-clean" option was not specified then the extracted files would remain in
> the PDK-userID directory. The "-clean" option was to then included the PID
> and remove bound files.
>
> The above statements are in reference to using the "-bind" option and not to
> PerlApp::extract_bound_file.
>
> From the docs:
> --clean
>
> Clean up object files that were extracted from the application at runtime.
> By default, these files are cached in the temporary directory. This allows
> the next invocation of the app to start up faster.
>
> Are not manually bound files subject to the above described default
> behavior?
> ________________________________________
> From: pdk-beta-bounces@[...].com
> [mailto:pdk-beta-bounces@[...].com] On Behalf Of Michael
> Nacey
> Sent: Tuesday, October 12, 2004 3:50 PM
> To: PDK-Beta@[...].com
> Subject: Re: [PDK-Beta] PerlApp extract bound file problem
>
> 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
>
>
>
>
>
>
>
>
>
--
Michael Nacey
Build Manager/Project Manager
Tele-Tracking Technologies, Inc. <http://www.teletracking.com>
Tele-Tracking Technologies, Inc. Email Confidentiality Disclaimer: The
information contained in this email is privileged and confidential and
is intended only for the use of the addressee(s) indicated above. Use or
disclosure of information emailed in error is prohibited. If you have
received this email in error, please contact the sender and immediately
delete the original message. Thank you.
Thread:
Howard A. Bullock
Howard A. Bullock
Jan Dubois
Howard A. Bullock
Michael Nacey
Michael Nacey
|