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.

#!/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

In terms of performance, would there be any difference between

#!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?

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!

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

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

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.

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

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

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.


HTH

 
 
 keep the rudder amid ship and beware the odd typo

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?

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

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

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?

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.