Actually, I think that this problem "triggered" the second problem above, by altering the order of execution of things... and the 2nd problem may be a bug in the script, undetected if the script has been run previously and initialized.
So I have a bunch of scripts that extract from their $0 the name of the script (such as app.pl), and use it as part of a registry key to set and find configuration values in the registry.
So when I pp --output app.exe app.pl
the resulting app.exe thinks it is app.exe instead of app.pl like it used to. So then it doesn't find its registry values, and "starts over".
So, having heard about $ENV{PAR_0} being the .pl script name, I modified one of my scripts a bit to use that instead of $0, if it existed.
At first I wondered how that would go if a pp-compiled script containing such code launched a plain script with similar code, but I didn't get that far: $ENV{PAR_0} doesn't end with app.pl as expected; instead it is f98107dc.pl. So that value doesn't work to access the registry values either.
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".
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.
When a PAR script launches another script, are things like PAR_0 removed from the environment? If not, what is the standard technique used to determine if PAR_0 was created for the current script, or for some prior script?
-- 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.
