On Wed, May 26, 2004 at 10:46:30AM +0200, Murphy wrote:
> >I do wonder whether it will be best if we simply assign one of the two to $0.
> >The reason it was not done before was (iirc) that assigning to $0 changes the
> >displayed program name in "ps", and (obviously) I'm not sure which of the two
> >should be assigned to $0.
>
> Personally, I think that $ENV{PAR_PROGNAME} should be assigned to $0
> because the $ENV{PAR_0} can always be found in:
>
> ( split(":", $ENV{PATH}) )[0];
Hmm? I fail to see how it can be obtained thus. $ENV{PAR_0} contains the name
to the extracted script, like "/tmp/par-autrijus/cache-xyz/f409617.pl".
The problem is there are two uses of $0. One is used by Pod::Usage,
and assumes $0 is a perl script:
open MYSELF, $0;
my @code = <MYSELF>;
# ...assuming @code contains lines of perl code...
Another use thinks $0 is the program invoked by the user:
my $file = basedir($0)."/file.txt";
# ...assuming $file exists in the same path as the invoked executable...
However, in a pp-generated executable, the first corresponds to $ENV{PAR_0},
and the second corresponds to $ENV{PAR_PROGNAME}.
> So I rather would expect to see the the par package name with the full path
> as it is normally done by the Perl in $0.
I am neutral (read: ambivalent) on this issue. In any case it should be
better documented -- patches welcome, really -- but I'm curious about whether
there are people in favor of the first use case (assuming $0 is a perl script file,
containing the same lines as *main::DATA). Anyone out there?
BTW, note that another idiom:
system($^X, $0, @new_arguments);
is partially supported if $0 is set to $ENV{PAR_0}, and if the target environment
does have perl installed. But I'm not sure if it is desirable to support this.
Thanks,
/Autrijus/
pgpt64QMp2zHE.pgp
Description: PGP signature
