scan the directory at start of running the script, then after the script is done, scan the directory again and delete the new dir if the dir name =~ /temp/par-xxxxx/

Race condition. Don't do that. While the pp "compiled" perl script runs, someone can change the contents of the directory, or even remove the directory and replace it with something else.

Almost all linux distributions come with some perl version and a package manager. To distribute a perl script, either use the system perl as script interpreter and create a package (*.rpm, *.deb, ...) that depends on it (and perhaps some pre-packaged modules from the distribution), or package a custom perl, perhaps some custom modules, and make the script depend on the custom perl and the custom modules. There is no need to bundle a huge amount of binaries (perl interpreter, libraries, modules) into a single executable that starts polluting the file system every time it is started just to distribute a perl script.

To make things worse, the bundled binaries are most likely already present on the target system, wasting space. And even more worse, security updates distributed to the target system won't update the pp bundled script, it will still have security problems, even on a patched target system.

Now imagine not one pp-packed script, but hundreds of them, all with their own copy of a vulnerable library, where patching the system library just won't help. Welcome to the latest nightmare of Java.

Plus, using pp limits the resulting executable to a single operating system on a single processor platform. While the perl script could run, for example, on MIPS, ARM, x86, and x64 on Linux, *BSD, MacOS, and Windows, running pp on Linux x64 limits the resulting executable to Linux x64.

Alexander