On approximately 7/28/2004 3:34 PM, came the following characters from the keyboard of Glenn Linderman:
On approximately 7/28/2004 1:40 PM, came the following characters from the keyboard of Alan Stewart:
Seems with the big long cache-gibberish path name, that the actual filenames could be used within the cache-gibberish directory-- it is not at all clear why the script has to have a different name when "extracted".
It's really awkward to do something that works in all cases. If PAR_TEMP is set, a PAR package doesn't generate different "cache-gibberish" names for each exe and they all go in one directory. Different names are needed to prevent collision of two scripts that started with the same name. You might not do that, but two authors of two PAR exe's might.
Yeah, I suppose. Too many options, eh? But wouldn't that also be problematical for PAR scripts with different versions of the same modules, both run under PAR_TEMP? So shouldn't "inc" be renamed to inc-gibberish, to avoid such problems?
So thinking about this some more, I guess I don't understand why the cache-gibberish gibberish is so much longer than the filename gibberish.
They are not removed. Again it's difficult to do all things. If all the PAR %ENV values are provided to your script, it's your script that launches the next script, so PAR has no way of removing environment variables prior to the launch.
OK, but my PAR enabled script could undef all %ENV entries that start match PAR_.* and resolve this issue?
OK, so here's a thought. There seems to be one "app.exe" that is the whole package, and one "app.exe" that is a renamed perl.exe ? Or something equivalent? So couldn't the renamed perl.exe actually override "CORE::system" "CORE::exec", and "Win32::Process::Create", and eliminate the PAR_ %ENV entries at that point? While some things are difficult to do, this one doesn't seem to be all that difficult. Or code could be inserted in front of the script to do these overrides.
Looking around, I also see that $^X is a nebulous, path-free "perl.exe". Seems like this would be a great place to put what is now in $0 ... and it would be true, also, if I understand things correctly. I'm not suggesting changing $0, just $^X.
I'm looking at code that creates shortcuts to a program, and it currently puts in "$^X $0" as the command to execute. Clearly this is code that won't work transparently under perl without PAR, and also with PAR 0.85.
Seems like it would be nice if there were a "tipsheet" of what might be likely to need to be changed when a Perl script is compiled with PAR. Neither the FAQ nor the tutorial contain such things as I'm discussing here. The following items come to mind, no doubt more will present themselves as time goes on...
1) $^X, $0, $ENV{PAR_0}, $ENV{PAR_PROGNAME}
2) how to obtain a consistent name derived from the script name for use with Registry data access (one way is to simply embed a constant in the script (and executable), instead of deriving from the script name, but that loses the flexibility of users renaming the program to get a different set of configuration settings).
3) how to obtain appropriate parameters for shortcuts
4) how to really use -a and -A and what differences are required in the code to access supporting files
-- 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.
