0

I have two perl scripts that I need to run together.

The first script defines a number of common functions and a main method.

Script 1(one.pl) Example: 

#!/usr/bin/perl
sub getInformation
{
  my $serverMode = $_[0];
  my $port = $_[1];
  return "You\nneed\nto\nparse\nme\nright\nnow\n!\n";
}

#main
&parseInformation(&getInformation($ARGV[0], $ARGV[1]));

The second is a script that calls the second script after defining two functions.

Script 2(two.pl) Example:

#!/usr/bin/perl
sub parseInformation
{
  my $parsedInformation = $_[0];
  #omitted
  print "$parsedInformation";
}

my $parameterOne = $ARGV[0];
my $parameterTwo = $ARGV[1];
do "./one.pl $parameterOne $parameterTwo";

Command line usage: 

> ./two.pl bayside 20

I have attempted to do this and the script seems to run however, whenever I run the script in perl -d two.pl mode I get no information from the debugger about the other script.

I have done some research and read about system, capture, require and do. If use the system function to run the script, how will I be able to export the functions defined in script two?

Questions:
1. Is there anyway to do this in perl?
2. If so how exactly do I need to achieve that?

I fully understand that perl is perl. Not another programming language. Unfortunately, when transitioning one tends to bring with what they knew with them. My apologies.

References:
How to run a per script from within a perl script
Perl documentation for require function

Community
  • 1
  • 1
Dodzi Dzakuma
  • 1,406
  • 2
  • 21
  • 39

2 Answers2

1

Generally speaking, that is not the way you should write reusable common functions in Perl. Instead, you should put the bulk of your code into Perl modules, and write just short scripts that act as wrappers for the modules. These short scripts should basically just grab and validate command-line arguments, pass those arguments to the modules for the real work, then format and output the results.

I really wish I could recommend perldoc perlmod to learn about writing modules, but it seems to mostly concentrate on the minutiae rather than a high-level overview of how to write and use a Perl module. Gabor Szabo's tutorial is perhaps a better place to start.

Here's a simple example, creating a script that outputs the Unix timestamp. This is the module:

# This file is called "lib/MyLib/DateTime.pm"
use strict;
use warnings;

package MyLib::DateTime;

use parent "Exporter";
our @EXPORT_OK = qw( get_timestamp );

sub get_timestamp {
    my $ts = time;
    return $ts;
}

1;

And this is the script that uses it:

#!/usr/bin/env perl
use strict;
use warnings;
use lib "/path/to/lib";   # path to the module we want, but
                          # excluding the "MyLib/DateTime.pm" part

use MyLib::DateTime qw( get_timestamp );  # import the function we want

# Here we might deal with input; e.g. @ARGV
# but as get_timestamp doesn't need any input, we don't
# have anything to do.

# Here we'll call the function we defined in the module.
my $result = get_timestamp();

# And here we'll do the output
print $result, "\n";

Now, running the script should output the current Unix timestamp. Another script that was doing something more complex with timestamps could also use MyLib::DateTime.

More importantly, another module which needed to do something with timestamps could use MyLib::DateTime. Putting logic into modules, and having those modules use each other is really the essence of CPAN. I've been demonstrating a really basic date and time library, but the king of datetime manipulation is the DateTime module on CPAN. This in turn uses DateTime::TimeZone.

The ease of re-using code, and the availability of a large repository of free, well-tested, and (mostly) well-documented modules on CPAN, is one of the key selling points of Perl.

tobyink
  • 13,478
  • 1
  • 23
  • 35
1

Exactly.

Running 2 separate scripts at the same time won't give either script access to the others functions at all. They are 2 completely separate processes. You need to use modules. The point of modules is so that you don't repeat yourself, often called "dry" programming. A simple rule of thumb is:

  1. If you are going to use a block of code more than once put it into a subroutine in the current script.
  2. If you are going to use the same block in several programs put it in a module.
  3. Also remember that common problems usually have a module on CPAN

That should be enough to get you going. Then if you're going to do much Perl Programming you should buy the book "Programming Perl" by Larry Wall, if you've programmed in other languages, or "Learning Perl" by Randal Schwartz if you're new to programming. I'm old fashioned so I have both books in print but you can still get them as ebooks. Also check out Perl.org as you're not alone.

Craig
  • 11
  • 2