On 28 Jul 2004 at 17:41, Glenn Linderman wrote:
> 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.
>
Well, long is better, less chance of a duplicate. The cache dir is created by the
binary frontend with a C fast code routine. Making the file temp names longer also
would be better but that happens at Perl code time and would add the dependency on
another Perl module to do it. As it is, the shorter names are inside a dir with a
longer name, so the chances of duplicate names in the same dir is very very small.
BTW, the official name for the short "gibberish" is CRC32 and the long "gibberish" is
an SHA1 hash :)
> 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.
There is no perl.exe when running a PAR exe. Perl.exe is just a thin loader that links
perl5x.dll and starts an interpreter for the script when you run from the command
line.
The binary frontend of a PAR package has two layers: the first extracts perl5x.dll and
the second exe layer to temp; The second layer (with the same name as the first) runs
a
lot like perl.exe, but starts the third layer next (par.pl) and that extracts and runs
your script.
You could remove all PAR environment variables in par.pl just before running your
script, but as I said, the PAR environment values (at least some of them) are there to
be used by scripts that are written to be PAR aware. It would have to be an option to
not pass them in.
A side opinion: It seems that the majority of people using PAR are packaging existing
programs and would prefer it to be a totally transparent wrapper with no side effects
in their script and no script changes necessary no matter how they use it. That's an
ideal goal, but I don't think it's possible. Some coding to accommodate PAR is going
to
be needed sometimes.
>
>
> Looking around, I also see that $^X is a nebulous, path-free "perl.exe".
That's perl (incorrectly) reporting perl.exe for $^X, not PAR. As noted, there was no
perl.exe involved.
> 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.
If your program is "app.exe" then "$^X $0" makes the shortcut "app.exe app.exe".
That's
not right either. Under perl you need two values, under PAR just one. I don't see how
you can get around checking if $0 ends in ".exe".
>
> 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.
That's true. But like all projects, bugs draw more attention than documemtation :)
> 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}
It's in the TODO list.
> 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.
>
