The perl.exe location depends on the installation tool that you are using. This doc on unattended installations may be of interest when it comes to adding ActiveState Perl since it uses it as an example.

As others have said, PAR is an excellent solution. If you have need to do this often, I've had excellent success with the commercial Perl "compiler" PerlApp, included with the ActiveState PDK. There's a cost, but it works very well and carries support from ActiveState if you ever have problems. If you're doing this for commercial distribution, especially, ActiveState is the way to go.

With either solution, you don't need to have Perl installed on the target machine, as it (and necessary modules) are packaged together inside the EXE. This carries the added advantage that your users can't break your programs by upgrading (or removing, etc.) their Perl modules.

As other monks have suggested, it's usually better to use a packer like par.

-Andrew.

Are your users on a corporate LAN? If so, place perl and your 7 scripts on a share and distribute a 10 line .cmd file that connects to the share and runs the scripts from there.

If properly configured, you need only add those machines to upgrade to the appropriate user group and they'll run your script automatically on boot, and remove themselves from the group when done.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Check out the PAR::Tutorial. My interpretation of the section starting "Aggregating multiple programs" is that one need not have a full PAR for each Perl program.

emc

" The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."
—Nathaniel S. Borenstein