Andreas Marienborg schrieb:
I use PAR + pp to deploy some applications needing perl 5.8.n in a 5.6.n
enviroment.
That works great
except for one small glitch.
It gets unpacked in /tmp/par-<username>
and the hosting company automaticly cleans some files under /tmp every
once in a while.
Now I'm wondering if I can somehow specify where it should be unpacked?
Sorry for the late answer. There are various ways to achieve this:
Set the TEMP env. variable to something like /home/myuser/my_temp/ in
the context in which you execute the program. It will usually create a
"myuser-par" directory in "my_temp" and in the par directory, individual
program caches will go into "cache-HASHOFEXECUTABLE".
The other way is to set PAR_GLOBAL_TEMP to something like
/home/myuser/my_cache_dir_for_program_foo/. Example:
PAR_GLOBAL_TEMP=/home/myuser/my_cache_dir_for_program_foo/ ./foo.bin
That will put the cache *directly* into
/home/myuser/my_cache_dir_for_program_foo and *not* into a subdirectory.
This means that you cannot use the same PAR_GLOBAL_TEMP setting for
different programs. Just use the TEMP var in that case.
I know this is suboptimal, but it's how it works right now.
Finally, you can modify the name of the "cache-HASHOFEXECUTABLE"
directory using the -T option of pp. But that won't help you.
I am aware all of this isn't exactly great for your situation. Possibly,
you can't even set environment variables (or only when the script
already runs). Perhaps there is a webserver option to set environment
variables for programs it executes. I have no idea, really. I wouldn't
know how to implement it differently either, though. If we add an option
to pp which would set the temporary directory to somewhere specific, the
executable would cease to work on different systems. In fact, if it
didn't work at all, that would be the best situation: It might overwrite
something instead!
Now as I come to think of it, there might be something we could do. But
I don't like it:
- "parl", the binary PAR loader which is prepended to every pp-ed
executable, supports a specific option "--par-options" after which all
command line switches are interpreted as options to "parl".
- If we add a "parl" option which sets the extraction directory, we can
select a directory on the target machine.
The problem I have with this approach has a couple of components:
- I do not understand the magic that makes parl work.
- I'm unsure how many ripples into the rest of the code base such an
option might introduce.
- parl in the context of pp-ed apps might (in some contexts?) be
replaced by a much simpler unzip based loader/extractor in the future.
If that happens, we will have to worry about the current supported set
of options anyway. Hence, adding to that might be a bad idea.
- If you want to put your app in a web server path and have it used as a
CGI, you can't have command line options either.
Steffen
