[Thamesvalley-pm] using third party perl scripts

Ismail, Rafiq (IT) Rafiq.Ismail at MorganStanley.com
Wed Oct 17 01:57:47 PDT 2007


I would probably suggest putting all your common/reused components/logic
in a module, where each of your scripts can share this. 

<morningRamble>
If, however, you're going to use do (perldoc -f do), which I'm not so
fond of, then I would recommend using such a pattern that insures you:

i) Minimise use/overlap of global variables between scripts
ii) Try and wrap your functionality in subroutines, as opposed to the
main body of the script 
Iii) If you can't go with (ii) then at least ensure that @ARGV is set to
the expected input of the included script.

When you do a 'do', you're basically evaluating the script into your
current execution thread.  So, if you have all your processing in the
main body of the script, dependent on the state of @ARGV - this might
cause confusion/collision when you evaluate the script from one which
has its own @ARGV and surrounding scope to deal with.  This is why it's
better to try and strip your processing out of the main body.

A way to get around this would be to have some main method which is
directly invoked when your script is executed - but not otherwise.
Further, if needed, try to return a result set which can be used by your
calling application.: 

fooMain(@ARGV) unless caller();

sub fooMain {
  my @args = @_;
  my @stuff;
#... Do stuff
  return @stuff; 
}


If your "do 'foo_script.pl'" succeeds, then you can directly call your
<script>Main() function and pass it your $pca_opts:

Unless (do 'fooScript.pl') {
	croak("could not eval script: $!")
}
My @pca_opts = split '\s', $pca_opts
My @results = fooMain( @pca_opts );


BTW, the reason I call it <script>Main is because you'd otherwise keep
redefining 'main' (assuming this is what you called your main methods)
with each new 'do <script>'.  

I've seen some horrid/bloated examples of reuse through do - and nasty
hard to find bugs from the side effects of global variables used across
multiple eval'ed scripts.  I still suggest re-use through a common
module.  

</morningRamble>
Raf





 

 

> -----Original Message-----
> From: 
> thamesvalley-pm-bounces+rafiq.ismail=morganstanley.com at pm.org 
> [mailto:thamesvalley-pm-bounces+rafiq.ismail=morganstanley.com
@pm.org] On Behalf Of Greg Matthews
> Sent: 16 October 2007 15:26
> To: ThamesValley Perl Mongers
> Subject: Re: [Thamesvalley-pm] using third party perl scripts
> 
> Charlie Harvey wrote:
> > Hey Greg,
> > 
> > Sounds like you need to use do or eval.
> > 
> > do EXPR
> 
> hrmmm.. not used that before... at the moment I'm using this approach:
> 
>      open(PCA, "$pca_bin $pca_opts |") or die "No fork: $!\n";
>      my @result = <PCA>;
>      close PCA;
> 
> and set $pca_bin to be the path to the perl utility. Is this 
> acceptable? 
> I'm using a very similar approach in order to use ssh from 
> perl. It works but I'm not clear if this is best practice.
> 
> its not clear from the docs whether you can capture output 
> from "do" (as I do above with the pipe).
> 
> G
> 
> > 
> > Uses the value of EXPR as a filename and executes the 
> contents of the 
> > file as a Perl script.
> > 
> >     do 'stat.pl';
> > 
> > is just like
> > 
> >     eval `cat stat.pl`
> > 
> > http://perldoc.perl.org/functions/do.html
> > 
> 
> 
> -- 
> Greg Matthews           01491 692445
> Head of UNIX/Linux, iTSS Wallingford
> 
> --
> This message (and any attachments) is for the recipient only. 
> NERC is subject to the Freedom of Information Act 2000 and 
> the contents of this email and any reply you make may be 
> disclosed by NERC unless it is exempt from release under the 
> Act. Any material supplied to NERC may be stored in an 
> electronic records management system.
> 
> _______________________________________________
> Thamesvalley-pm mailing list
> Thamesvalley-pm at pm.org
> http://mail.pm.org/mailman/listinfo/thamesvalley-pm
>
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.


More information about the Thamesvalley-pm mailing list