Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Script calling Script

Script calling Script

Script calling Script

Is system perl anotherscript.pl the best way of calling/co-ordinating the calling of another script by another master script?

RE: Script calling Script

All depends on what you are trying to do.  

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.

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.


 keep the rudder amid ship and beware the odd typo

RE: Script calling Script

In terms of performance, would there be any difference between

require anotherScript.pl
#sub anotherSub defined in anotherScript.pl

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

Nothing noticable, perl does about 10,000 lines of code/second (parsing and stuff) so it is a negligible slowdown if you just paste it.  

As always, I hope that helped!

Beware: Studies have shown that research causes cancer in lab rats.

RE: Script calling Script

I have variables defined in the parent script that the anotherscript.pl need to reference!
how could I do that?

RE: Script calling Script

If you need to pass a few (2 or 3 or 4 ) to 'anotherScript.pl', then you could pass them as args in the system call.


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').

require anotherScript.pl;

$var1 = 'something';
$var2 = 'something else';

&anotherSub($var1,$var2); #another sub resides in anotherScript.pl


 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
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


RE: Script calling Script

You are correct.  Doing a require makes it appear that anotherScript.pl has been copied into parentScript.pl.  All variables that have been set before you call a sub in anotherScript.pl carry their values.  There is a difference between use and require.

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.


 keep the rudder amid ship and beware the odd typo

RE: Script calling Script

I have a query regarding the use   require.  
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

You can use 'die' to bail out or 'exit'.

The use of 'my' restricts the scope of the target variable to the enclosing block.

$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...



 keep the rudder amid ship and beware the odd typo

RE: Script calling Script

Two questions,
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

Here's a partial answer to your questions above:

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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

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.

Join Us             Close