Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Script calling Script 1
- Thread starter drkestrel
- Start date
-
1
- #2
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 [red]|[/red]" 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
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 [red]|[/red]"
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
- Thread starter
- #3
In terms of performance, would there be any difference between
and copying and pasting the code for
from
to the current script?
Also, is it a 'normal practice' to use
or
?
I assume that
is only useful if
would print to STDOUT or STDERR?
Code:
#!usr/local/bin/perl
require anotherScript.pl
#sub anotherSub defined in anotherScript.pl
anotherSub();and copying and pasting the code for
Code:
anotherSub
Code:
anotherScript.plAlso, is it a 'normal practice' to use
Code:
require
Code:
systemI assume that
Code:
pipe
Code:
anotherscript.plNothing 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.
Disclaimer:
Beware: Studies have shown that research causes cancer in lab rats.
- Thread starter
- #5
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
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
- Thread starter
- #7
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
or
Ta
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
Code:
use
Code:
requireTa
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
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
- Thread starter
- #9
I have a query regarding the use
.
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
mean in Script B?
Code:
requireSay 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
Code:
myYou 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
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
- Thread starter
- #11
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?
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.
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.
- Status