As usual with perl, there is more than one way to do it. You might just use system to call a new perl process, but the more standard way to do it would be to use do. You can set @ARGV to define the parameters for the other scrips.
{
local @ARGV = ("Two", "Parameters");
do "other_script.pl";
}
#here other_script's execution is done
If other_script returns a true value (eg: the last line in other_script.pl is "1") then you can write:
{
local @ARGV = ();
do "other_script.pl" or die "Other script failed: $@";
}
Error information will likely be in $@, but you might need to check $!, read do's documentation for more detail.
Edit: the advantages of do over system are that it does not create a separate perl process, and the output is usable as perl data. | [reply] [d/l] [select] |
I agree that do might be suitable and have advantages, but for the OP I have to point out some caveats: The code executed by the do will also see package variables from the surrounding scope, and will be sharing globals like $/ with the rest of the code. If one of the scripts sets these variables to something (without properly localizing it), it will affect all the other scripts. This is not the case with system, since it'll be a totally separate process. Here's how one might do that, with appropriatebasic error checking (see $^X, as well as system for how to interpret $?). It would be best if $scriptname were an absolute pathname.
system($^X,$scriptname,@args)==0
or die "$^X $scriptname failed, \$?=$?";
Of course, whether it is a good set-up to have one Perl script call several other scripts, instead of having one script (properly modularized) do it all, might be questionable in the first place. | [reply] [d/l] [select] |
Thank you for your answer, I did think about the vertical issue with these variables (the caller modifies a variable which is used by the callee), but didn't think about the horizontal problem (variables from one callee not restored for the next).
| [reply] |
The script that will run the others is in the same directory as them
As I mentioned in my post here, it would be best if you use absolute pathnames. If you don't want to work with hard coded paths in your scripts, here's one thing you can do instead to still get absolute paths (note File::Spec and FindBin are core modules):
use File::Spec::Functions qw/catfile/;
use FindBin;
my $scriptname = catfile($FindBin::Bin, "foo.pl");
| [reply] [d/l] |
Hi,
Perhaps you could just incorporate the other progs into the calling prog, each in it's own sub, called in turn..
Might be simpler ...
J.C.
| [reply] |