On 28 Jul 2004 at 12:26, Glenn Linderman wrote:
>
> 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.
>
PAR_0 isn't really intended to get the program name, but perhaps for some program that
needs to parse itself and extract data. PAR_PROGNAME is available as a synonym for $0.
> 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.
> 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.
> 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?
>
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. And maybe you want to
pass them (or not). If your second script is a PAR package then all the PAR variables
are for the second script while in that script. If the second script is not a PAR
package, it will see all the environment for the parent program.
If you want a PAR exe to launch a script that may or may not have been PAR packaged
and
the launched script needs to determine if PAR variables are valid, you could use
$ENV{PAR_PROGNAME) as the trigger variable and undef it in the parent program before
launching the second script. There was another way to know if you are running under
PAR
or not, that was mentioned in this list, but I am spacing out on what it was. Anybody?
Alan Stewart
