pp's tmp folder content execution

DomX has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks, here monk Dominik, asking my siblings for wisdom.

I'm a fan of using pp to make standalone programs since v5.40.0, because it lets me use the new Perls and doesn't mess the target system by installing anything by sudo cpan somewhere nobody is finding things again or making updates at all.

Long story short: Delivering a pp archive is already pretty neat, but I'd like to go a step further. The application extracts itself to /tmp/par-<user name hash>/cache-<app hash or -T string> (or similar) by default. So, what I thought, to reduce the startup time, which is really poor for pp executables, compared to native Perl, I'd like to omit the extraction and verification step of the pp binary, but directly start the interpreter from the /tmp/par-.../cache-... directory, with the script as argument. Something I think the pp binary is doing. But the executables and libraries have very obscure names, so I don't know, what exact I need to execute to start up the interpreter from /tmp/par-.../cache-...

Maybe I'm completely wrong on this path anyway and this is any magic within the pp binary itself, not just from this folder.

So, what I actually try to achieve is: having a unpacked Perl interpreter, running my scripts, for example:

$ cat /usr/bin/myapp
#!/usr/bin/env bash

/usr/libexec/myapp/perl /usr/libexec/myapp/myapp.pl "$@"
[download]

I know, I could just compile a Perl residing entirely withing /usr/libexec/myapp, but maybe there is a more simple way to do so?

Comment on pp's tmp folder content execution Download Code

Replies are listed 'Best First'.
Re: pp's tmp folder content execution by bliako (Abbot) on Feb 20, 2026 at 10:35 UTC
First do a survey of what are the contents of the packed archive. Most likely the vast majority are binary libraries which perl depends on. Logically, in this case, your best option is to install a complete Perl in your target system, if you can. Additional benefit is that these libraries can be reused instead of each packed archive using their own. You can install Perl and modules in your target system but still have your program packed and run by PAR which will not include any Perl dependencies. This will result in a much smaller archive, hence faster extraction. See Perl-interpreter-only,-without-core-modules: of pp and Perl-with-PAR.pm-and-its-dependencies-installed: of pp. In this way you have the best of both worlds, (1) Perl installed in your target system once, and (2) you can distribute your program(s) as single executables of very small size as many times as you like. If you want to extract once and use forever, then you can use saner filenames with `-T or --tempcache` (see -T,-tempcache of pp) to specify something else instead of an ugly hash. Most importantly, you can change the first part of the extract-to directory (i.e. the `/tmp/...`). See PAR::Environment and `PAR_GLOBAL_TEMP` etc. If you are in Linux, you can extract into a temporary RAM-based dir: as root, `mount -t tmpfs -o size=500m tmpfs /myramdir` and then set `PAR_GLOBAL_TEMP` to `/myramdir`. Your program will live there until reboot or unmount. That will be faster though ephemeral. Also, there is the option of running perl through a docker linux container. Theoretically talking, your container should include perl and all module dependencies. Your program can be inside or outside the container.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: pp's tmp folder content execution
by bliako (Abbot) on Feb 20, 2026 at 10:35 UTC

First do a survey of what are the contents of the packed archive. Most likely the vast majority are binary libraries which perl depends on. Logically, in this case, your best option is to install a complete Perl in your target system, if you can. Additional benefit is that these libraries can be reused instead of each packed archive using their own.

You can install Perl and modules in your target system but still have your program packed and run by PAR which will not include any Perl dependencies. This will result in a much smaller archive, hence faster extraction. See Perl-interpreter-only,-without-core-modules: of pp and Perl-with-PAR.pm-and-its-dependencies-installed: of pp. In this way you have the best of both worlds, (1) Perl installed in your target system once, and (2) you can distribute your program(s) as single executables of very small size as many times as you like.

If you want to extract once and use forever, then you can use saner filenames with -T or --tempcache (see -T,-tempcache of pp) to specify something else instead of an ugly hash. Most importantly, you can change the first part of the extract-to directory (i.e. the /tmp/...). See PAR::Environment and PAR_GLOBAL_TEMP etc.

If you are in Linux, you can extract into a temporary RAM-based dir: as root, mount -t tmpfs -o size=500m tmpfs /myramdir and then set PAR_GLOBAL_TEMP to /myramdir. Your program will live there until reboot or unmount. That will be faster though ephemeral.

Also, there is the option of running perl through a docker linux container. Theoretically talking, your container should include perl and all module dependencies. Your program can be inside or outside the container.

[reply]
[d/l]
[select]