#! /usr/bin/perl.
[download]

The reason I need to do this is because I have a lot of Perl scripts written/maintained by someone else. I would like to pull them unmodified into my test harness and execute functions inside them without having to modify the code.

Hope this clears it up and thanks for all the help. -brad w.

Actually, you can require them. However, if there is any code inside that isn't wrapped in a sub, it will execute when the file is required. Example:

#!/usr/bin/perl
### the file doing the requiring

use strict;
use warnings;

use lib '/path/to/lib';
require('tmp.pl');

asdf();
[download]

---

#!/usr/bin/perl
### the file being required

use strict;
use warnings;

print "hi there\n";

sub asdf { print "well howdy"; }

1;
[download]

---

### the output
hi there
well howdy
[download]


---
It's all fine and dandy until someone has to look at the code.

Ok, so if I understand, you've got a script running, and within one of its used modules you wish to probe a completely different script to see if a particular function exists. Is that right?

Maybe you should search for that sub's name in the output from B::Xref.




Dave

That is correct..

-brad w.

Congratulations, you are re-inventing the Perl4 idiom for including subroutine libraries! From perlfunc

do EXPR

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`;

except that it's more efficient and concise, keeps track of the current filename for error messages, searches the @INC directories, and updates %INC if the file is found. See Predefined Names in the perlvar manpage for these variables. It also differs in that code evaluated with do FILENAME cannot see lexicals in the enclosing scope; eval STRING does. It's the same, however, in that it does reparse the file every time you call it, so you probably don't want to do this inside a loop.

If do cannot read the file, it returns undef and sets $! to the error. If do can read the file but cannot compile it, it returns undef and sets an error message in $@. If the file is successfully compiled, do returns the value of the last expression evaluated.

Note that inclusion of library modules is better done with the use and require operators, which also do automatic error checking and raise an exception if there's a problem.

You might like to use do to read in a program configuration file. Manual error checking can be done this way:

        # read in config files: system first, then user
        for $file ("/share/prog/defaults.rc",
                   "$ENV{HOME}/.someprogrc")
           {
            unless ($return = do $file) {
                warn "couldn't parse $file: $@" if $@;
                warn "couldn't do $file: $!"    unless defined $return
+;
                warn "couldn't run $file"       unless $return;
            }
        }
[download]

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

We appear to be miscommunicating... I made no mention of do in my reply, nor used it in my code. I do not recommend its use for something like this. The point of my previous post was to illustrate that the OP can require the file, but anything in it will be executed. It was a cautionary example.

Hopefully I'm not missing anything in your reply that would make it pertinent to mine.

---
It's all fine and dandy until someone has to look at the code.