Operating System - Linux
1752672 Members
5874 Online
108789 Solutions
New Discussion юеВ

How to Execute a PERL Module as a Normal Script

 
CA1490051
Frequent Advisor

How to Execute a PERL Module as a Normal Script

Hi All,

In Linux i tried to execute a Perl Script
that calls a subroutine defined in another file which i am including as a package in the main perl script.

Now my question is can i execute this Perl module having the function defined as a Perl Script.

Also can i execute the Package as a stand alone Script if the package in turn calls a function defined in Some other file.


Ex -

Main.pl

#!/usr/bin/perl
use Pack1;
Pack1::FirstRoutine();


Pack1 File looks as below

package Pack1;
use Pack2;

sub FirstRoutine
{
print "\n I am in first Package\n";}
Pack2::SecondRoutine();

Pack2 File looks as below

package Pack2;
sub SecondRoutine
{
print "\n I am in Second Package\n";}



Now i want to execute the Pack1.pm file directly

Can any one help me out of this

thnaks in advance
Vikram
2 REPLIES 2
James R. Ferguson
Acclaimed Contributor

Re: How to Execute a PERL Module as a Normal Script

Hi Vikram:

I'm not sure I understand. The Perl module is the fundamental building block of code re-use with 'use' and 'require' controlling its incorporation.

Too, your Perl program can call external entities via 'system' or by using 'backticks', and then there are 'piped' open() methods, too, to connect external programs.

By more direct answer to your question, "Now I want to executre the Pack1.pm file directly": Why can't it be a standalone module that you reuse as needed?

Regards!

...JRF...
Ralph Grothe
Honored Contributor

Re: How to Execute a PERL Module as a Normal Script

You could "do" an external Perl script
(see perldoc -f do; perldoc perlmod).
But real Perl modules simply aren't meant
to be executed stand-alone.
They are instead intended to be loaded
by a "use" or "require" into the callers namespace.
But this has already been mentioned by James.

If your module follows a more procedural approach then the Exporter module can very much ease the controlled import of vars, subs, handles, whatever without necessarily cluttering the caller's namespace.

On the other hand, a pure object oriented module doesn't require this conventional import of types (in fact even shouldn't at all) but instead should offer a constructor (whose guise in Perl lacks the usual formality of "real" OO languages, and only by convention often is called new()), accessor methods and other object methods.

If you don't like reading the excellent POD regarding modules and OO, as well as tutorials, (type "perldoc perl" to get a list),
then I would suggest getting a good book that treats these things.
Not to mention the notorious Camel Book,
I would suggest getting a copy of "Intermediate Perl" by Schwart and Foy

http://www.oreilly.com/catalog/intermediateperl/

No, I don't get a commission by O'Reilly ;-)




Madness, thy name is system administration