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?
Clearly I _could_ write code to just notice that $0 ends in .exe, and if $ENV{PAR_0} is set, then I could just change the .exe to .pl -- but this renaming makes things confusing. Yet modules seem to retain their original names.... so it seems that if scripts retained their original names, that less code would have to be changed to make things work under PAR.
$0 =~ s/\.exe$/\.pl/ seems easy enough :) It's a no-op if not a PAR exe.
Yeah, that's easy enough.
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?
-- 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.
