On approximately 12/30/2003 7:56 AM, came the following characters from the keyboard of Morbus Iff:
Besides the utf8 problems, there were two things that were bugging me about PAR, things that were stopping me from shipping it to end-users:
a) The generated .exe was renamed internally to par.exe whenever it ran. This has since been fixed (and just recently confirmed here) in 0.76_99. Awesome.
b) The name of the temp directory was based off the process ID of the running application. I believe that this decision was made to stop the application from clobbering old versions that were not properly deleted from the tmpdir (is this right?). But, this is causing a problem. See below.
To duplicate this problem on Windows, install ZoneAlarm, and then create the following executable:
pp -e "use LWP::Simple; getprint('http://disobey.com/');"
Now, run a.exe multiple times. Each time, the ZoneAlarm firewall will treat it as a brand new program, since the path is different for each run (in my cases, something like:
C:\Documents and Settings\Local Settings\Temp\par_priv.504\tmp\a.exe
with the "504" (being the process ID) changing for each iteration. In a nutshell, I need to remove that process ID, else I can't safely ship it to end-users without telling them to add a new rule in their firewall for each and everytime they want to run the program.
What would be nearly perfect would be if:
* I could say "hey! store the temp extracted files into "./data/internal", so, if C:\AmphetaDesk\AmphetaDesk.exe, it'd extract to C:\AmphetaDesk\data\internal\. This would allow me to feel good about telling people that AmphetaDesk munges with only it's directory, and no where else.
In poking through this, it appears that PAR/myldr/mktmpdir.c will be some help. Within, I can see the following (snippeted):
/* construct our private temporary directory under the tmp dir */ procid = getpid(); stmpdir = (char *)malloc(strlen(ptmpdir) + strlen(subdirbuf_prefix) + strlen(subdirbuf_suffix) + maxlen_procid + 2); #ifdef WIN32 sprintf(stmpdir, "%s\\%s%u%s", tmpdir, subdirbuf_prefix, procid, subdirbuf_suffix); #else sprintf(stmpdir, "%s/%s%u%s", tmpdir, subdirbuf_prefix, procid, subdirbuf_suffix); #endif
Concerning my process ID issue, it seems to be as simple as removing the "procid" mention from the first sprintf, and then recompiling PAR. It
seems so obliviously simple here that I've not tested it for this
discussion. If it's not obvious, certainly someone let me know.
But, what about "./data/internal"? At the beginning of the file:
const char *par_tmp_dir = "PAR_TMP_DIR="; const char *par_priv_tmp_dir = "PAR_TEMP=";
if ( (envtmp = (char *)getenv("PAR_TEMP")) ) { return envtmp; }
which would seem to enforce the idea that I could set an env var called "PAR_TEMP", pointed to "./data/internal/", then build my .exe, and things
should magically work, right? So, I open a DOS window, run:
SET PAR_TEMP = "./data/internal" SET (this command confirms it was set)
and then ran the same script as above. I also manually created the data/internal structure for the sake of testing. This seemed to cause the .exe NOT to work (there was no output and no errors). Thinking that perhaps it was Windows path delimiters, I tried:
SET PAR_TEMP = "data\internal\"
and received the following:
creation of "data\internal\"/perl56.dll failed - aborting with 22
I can't seem to figure out how to properly use PAR_TEMP to do what I want. Any ideas?
Drop the " and the spaces
set PAR_TEMP=data\internal\
or maybe
set PAR_TEMP=data/internal
Does PAR_TEMP affect the compilation of the package, or does it affect the runtime of the resultant package? (I'm not yet a heavy PAR user, but soon, I hope)
-- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.
