perl standalone to run perl script as a parameter

[eammendola]

Wise Monks, I am looking for a way to write a perl script which will be compiled into a standalone executable which will take another perl script as a parameter and run it against the standalone Perl. It will run on Windows clients, not having Perl installed. This is a requirement. For example, using Strawberry Perl and Per2Exe (I can't get pp to install correctly). I have a script called runperl.pl looks something like this:

$ret = `$^X $ARGV[0]`;
or
system('$^X $ARGV[0]');

I want to make it into a standalone exe and then pass it a script (runperl.exe dostuff.pl), where dostuff.pl runs on the standalone interpreter/compiler. Using standard system command (e.g. $foo = `perl bar.pl`;) compiles but can't find "perl". Using the variables in the example above won't even compile. Note: I can't put Strawberry on the client machines, it's too large. I'm looking to drop an executable that is small like 10MB or much smaller.

[chromatic]

Back up a step.

Do you need the ability to run one script from another, or do you have multiple scripts, each of which do different things, and you need to do those different things all from one process?

Put another way, why do you say you need to run a different script from the first one?

(The advice we give you will be different depending on what you're trying to accomplish, not how you have tried to accomplish it.)

[eammendola]

Fair enough. I may be asking the question incorrectly. I'll back up a bit and explain why I am trying to do what I am trying to do. And I really appreciate your guy's patience.

I am using a tool (IBM TEM) that can launch different types of processes on remote PCs. For example, I can tell it to run "perl myscript.pl" or "dir *.err" in a specific folder on a PC and use the processes to collect inventory data from that PC.

I cannot (by policy) install Perl on these PCs. I can however, have a standalone perl.exe on them to use at my discretion.

I am currently using a simple perl.exe (standalone) in a folder with some other tools. I did not make this exe, it was compiled by someone else (no longer here). I am calling this perl.exe remotely to run a configuration script written in Perl. The configuration script runs some system commands and parses the returned data. All that works.

My example: "perl invconfig.pl"

My dilema:

1. I need to change the abilities of the standalone perl.exe. I need a standalone perl.exe which has a few specific modules compiled with it AND probably have it be able to accept the configuration script as the parameter. For example, I want to add the Win32::TieRegistry module.

2. I "could" compile the configuration script, along with the necessary modules and any command changes each time I need to update the invconfig.pl. In that case I would just run the invconfig as a standalone exe. I would like to avoid that and leave the perl.exe unchanged and only changing the invconfig.pl, as needed. The configuration script gets updated regularly, adding and/or removing commands as needed. Because of this I don't want to have to recompile it each time. I also would like others to be able to do simple modifications to the invconfig.pl without having to recompile it.

So, ultimately I am trying to have a custom perl.exe that will only get rare updates (as needed), that will run a perl script and provide any required modules to it.

I don't completely understand what has to be in the custom perl.pl when I do Perl2Exe on it, so that it is able to run the configuration script.

My examples in my original question show what I was attempting to do, but they do not work.

If I compile it with this line, which I would guess should always run the same configuration script:  $ret = `perl invconfig.pl`; when I try to run the custom perl.exe like this "customperl.exe", perl says it can't find perl (or similar error).

If I try to compile it with one of these lines, presumably to locate the custom perl to execute the passed in script name:

$ret = `$^X $ARGV[0]`;
or
system('$^X $ARGV[0]');

I get a warning that perl is not found in the path during compile time.

I'm trying to use a standalone perl to call itself and run a script. I can limit the placement to a single folder if necessary. Perhaps, I am approaching this whole thing incorrectly. I just don't know.

[dasgar]

Based on what you're describing, I personally would approach this in a totally different manner.

It sounds like you're running something on a central system that issues remote commands to remote systems. That sounds like a network is involved. If so, the solution is very simple if you have the remote systems access a file share on the network.

Here's what I would do in your situation:

• Download a portable version of Strawberry Perl from here.
• Put the unzipped portable Strawberry Perl in a shared network folder that can be accessed by the "client" systems.

With portable Strawberry Perl, you're not installing Perl. Instead, you run a batch file that opens a command prompt and sets environment variables for just that command prompt. From that command prompt and only that command prompt, you can run Perl. With a little batch file tweaking, you can modify it to take inputs (such as the Perl script to run) and then it can run a Perl script with the full Perl environment.

For example, I want to add the Win32::TieRegistry module.

To have that or any other Perl module available, you just need to install those modules into the portable Strawberry Perl that's on that network share and then all of your "client" systems can use that module.

To allow others to run their modified version of the Perl script without installing Perl on the remote systems, I believe this may be one of the easiest methods to do so.

[CountZero]

I cannot (by policy) install Perl on these PCs. I can however, have a standalone perl.exe on them to use at my discretion.

Come one, give us a break! What is the difference between an "installed" Perl and a "standalone" Perl? Someone has been selling your IT security guys snake-oil.

Download a portable Strawberry Perl on a clean PC, install all modules you need, zip it up again and put it on your target computers. Sell it as the new "standalone Perl" and enjoy full perliness on your machines.

[Anonymous Monk]

I don't completely understand what has to be in the custom perl.pl when I do Perl2Exe on it, so that it is able to run the configuration script.

Tutorials: Including files, Simple Module Tutorial, perlvar#@ARGV, require, Config::Model/ config-edit#-ui

[CountZero]

Your runperl.exe doesn't seem to do anything else than what perl.exe already does.

On my windows system, the perl executable is less than 2 MByte, but the whole of my perl-installation is almost 37,000 files in over 9,000 folders for about 1.5 Gbyte. It are the modules that will really add to the size.

If you want to run any perl-script, you will have to install all of CPAN otherwise there is no guarantee at all that you can run any script.

[eammendola]

I should clarify. I am planning to only feed the runperl.exe with one or two "specific" .pl scripts. They will be thoroughly tested to work with my .exe. I may compile a few additional modules into the executable, but nothing more. I would not expect the runperl.exe to handle any random .pl I handed it. I'm sure that I am missing something here, but this does not explain how to call the standalone perl intrepretor from within the standalone perl intrepretor.

[Anonymous Monk]

See Re: Pack multiple scripts in executables with one shared core dll

[Anonymous Monk]

FYI, I am also investigating this. It will take me some time to digest.