Script calling Script
Script calling Script
(OP)
Is system perl anotherscript.pl the best way of calling/co-ordinating the calling of another script by another master script?
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS Contact USThanks. We have received your request and will respond promptly. Come Join Us!Are you a
Computer / IT professional? Join Tek-Tips Forums!
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail. Posting Guidelines |
|
Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.
Here's Why Members Love Tek-Tips Forums:
Register now while it's still free!
Already a member? Close this window and log in.
RE: Script calling Script
System will work. It forks a new process for the called code, waits for it to complete and returns the exit status from the called code. If that is what you need done, then system is the trick.
$exit_status = system("command","arg1",'arg2");
$exit_status = $exit_status/256; # the status from system is a little weird
Pipes are another, slight more complicated approach. With a pipe, you can spawn a child process and listen to the STDOUT from that child. So, if you want to catch some content from the child, a system call would be insufficient and a PIPE would be the way to go. It looks like opening a file, except that there is a '|' in the syntax.
open(PIPE,"command |") or die "Failed to open PIPE, $!\n";
while (<PIPE>) { $results .= $_; }
close PIPE;
If you are simply trying to gain access to a library of subs/functions, then use require.
#!/usr/local/bin/perl
require SomeOther.pl
#.....more code here which makes use of the contents of SomeOther.pl
This a brief overview. There is a lot more to think about after you scratch the surface.
HTH
keep the rudder amid ship and beware the odd typo
RE: Script calling Script
#!usr/local/bin/perl
require anotherScript.pl
#sub anotherSub defined in anotherScript.pl
anotherSub();
and copying and pasting the code for anotherSub from anotherScript.pl to the current script?
Also, is it a 'normal practice' to use require
or system ?
I assume that pipe is only useful if anotherscript.pl would print to STDOUT or STDERR?
RE: Script calling Script
As always, I hope that helped!
Disclaimer:
Beware: Studies have shown that research causes cancer in lab rats.
RE: Script calling Script
how could I do that?
RE: Script calling Script
system("anotherScript.pl","$arg1","$arg2","$arg3");
If you employ require, then the variables will be set. In oversimplified terms, require pulls the required code in and adds it to the code that is requiring it. It includes it in the compile as if the two become one. Unless anotherScript.pl is ENORMOUS, I don't see how you would notice any slow down (provided there are not logical problems in 'anotherScript.pl').
#!/usr/local/bin/perl
require anotherScript.pl;
$var1 = 'something';
$var2 = 'something else';
&anotherSub($var1,$var2); #another sub resides in anotherScript.pl
HTH
keep the rudder amid ship and beware the odd typo
RE: Script calling Script
For require
do you mean if parent.pl require anotherScript.pl
then
1) it behaves just like copying and pasting everything from anotherscript.pl into parent.pl
2) all variables in parent.pl could be used by anotherScript.pl?
3) It is just a perl script that I need 'requiring'. Any difference here between use or require
Ta
RE: Script calling Script
This may get a little deeper than you want. Let's start by saying that conceptually, require is a part of use.
require, as typically used, enforces a dependency on the required program. It executes that program and pulls into the requiring code. According to the Camel book, it checks to see that any required chunk has not already been loaded. If you have a second piece of code that has some normal plain vanilla subs that you want to employ (i can't use the word 'use' here), then do a require.
use, conceptually, does a require, and then imports items from the required code into the current name space. In otherwords, default behaviors may exist and be superceded by replacements specified by the import method which is defined in the required code. Huh? There must be a better way to say that! If you have a module that is pretty nasty and plays with namespaces and does some heavy duty playing with Perl internals, then you might want to do some heavy reading about use. The only time I ever employ use is when I am using a module that expects to be used ( most modules, I think).
If you want to know the details, we would have to get into the function of the Exporter class which is part of core Perl and that is more than I want to think about at the moment.
Just be aware that you need to watch your variable scoping when doing these tricks. The use of my and local is a good thing.
This is my understanding of this issue. If I am off track somewhere, I expect the rest of you to straighten me out.
HTH
keep the rudder amid ship and beware the odd typo
RE: Script calling Script
Say Script A call a subroutine ftp() in Script B. Could I put anything (other than die??) in Script B's ftp() subroutine that would abort the whole script if/when script A call script B's ftp() subroutine and something horribly goes wrong.
Also, regardiing 'scoping', I take that Script A require Script B is equivalent to copying & pasting all codes from Script B into Script A. In this case, what would my mean in Script B?
RE: Script calling Script
The use of 'my' restricts the scope of the target variable to the enclosing block.
Example
#!perl
$str = '123';
if ($str =~ /2/)
{
my $str = 'matched';
print "$str\n"; # this will display the word 'matched'
}
print "$str\n"; # this will display the numeric series '123'
The second (inner) use of $str is a separate variable from the first, two different locations in memory. The output from the above snippet looks like...
matched
123
HTH
keep the rudder amid ship and beware the odd typo
RE: Script calling Script
1) If I have Script A required Script B,then if I have procedure A in Script A calling procedure B1 in Script B. Assuming under certain conditions in procedure B1, the whole process (including procedure A) should be aborted, would exit simply exit out of the inner most control structure(e.g. if...else, foreach,sub) or could it 'abort' Procedure A as well?
2) My concerns about scoping is really as follows- what will 'appears' to Script A if
Script A requires Scripts B and C
Script B have my $var1, $var2, my $var3
Script C have my $var1, my $var2, my $var3
Also, if I have a sub-routine that is used by all 3 scripts, where should it be put/required?
RE: Script calling Script
exit should exit perl completely, including any loops, subroutines, etc.
if scripts B and C use "my" then script A should not be able to see those variables at all.
you can require the common script in any of the other scripts, or even in ALL of them just to be sure. perl will check to see if the script has already been require'd before.