From the perldocs:

do EXPR

Uses the value of EXPR as a filename and executes the contents of the file as a Perl script. Its primary use is to include subroutines from a Perl subroutine library.

do 'stat.pl'; [download]

is just like

scalar eval `cat stat.pl`; [download]

except that it's more efficient and concise, keeps track of the current filename for error messages, searches the @INC libraries, and updates %INC if the file is found. 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]

Thank you! I knew it had to be something simple, but I couldn't find it for the life of me.

I have the funny feeling when you talk about dealing with different namespaces, you really mean different scopes, and that "code evaluated with do FILENAME cannot see lexicals in the enclosing scope" bit will defeat you. Which means either going the route of reading the file in and eval'ing it, or not trying to share lexicals with the included code.

So it's perfectly ok to e.g. have a Foo.pm file containing:

# Warnings, strict and our aren't needed if you don't 
# want to bother. I Just like to have them
use strict;
use warnings;
our $c = 5;
sub foo {
    print $c;
}

# Next line is the only thing that's different from
# what you'd have if you were going to use "do"
# A filed being required/used should return something true
1;
[download]

And then use that as:

use Foo();
use strict;
# you couldn't call foo without () under use strict 
# if you had used "require" or "do"
foo;
our $c;
print $c;
[download]

Notice the () in use Foo(). It avoids a call to import, though supposedly if you use this you won't have a Foo package and there will be no import there, so you could leave them out too.

Having said that, it's still often a good idea to make commonly used code into a real module. You can use the Exporter if you want subs and variables in there available unqualified in your main code. It's only a few trivial lines more:

package Foo;                 # This line is new
use strict;
use warnings;
use base qw(Exporter);       # This line is new
our @EXPORT_OK =qw($c foo);  # This line is new, stuff the caller MAY 
+import to use it unqualified
our $c = 5;
sub foo {
    print $c;
}

1;
[download]

# Next line is different, explicitely say we want to use foo unqualifi
+ed (without Foo::)
use Foo qw(foo);            
use strict;
foo;
# We could also have listed $c in the import list and then use plain $
+c
# But let's instead show you can still access it by qualifying 
print $Foo::c;
[download]

Then once you've got your modules, you can put them in one place so that all your apps can get to them by doing something like this:

  use lib '/path/to/your/module/directory';
  use your_module1;
  use your_module2;
[download]

It just seems silly to me to clutter the code with extra modules and deal with exporting when I'll want the same symbols every time. I'll try use() again, I think having to declare variables in both files was what was messing me up. It seems like it should work just by using our() in the included file though.

I don't have code at my fingertips to show you, but you don't have to declare variables in both files. If the export is done properly in the module, you can simply refer to the variables in the code that does the "use". I hope I'm not oversimplying here - it's been a while since I've done this, and I'm not actively using Perl now.

I also think when I did create modules that I used a simplified approach of not doing "export"s at all. The "use" still worked the same, but to refer to variables in the module I had to use the module name, something like this:

   use lib '/path/to/my/module/directory';
   use MyMod;

   print "MyMod var1 value is $MyMod::var1\n";
[download]

Again, not sure if this is exactly right, but it should be close. I liked this approach because looking at the code you can always tell *where* a variable comes from - you don't need to go hunting around for it if you see that it hasn't been declared in the current module. You *are* using warnings(-w), strict, and declaring all your variables with "my", right??

HTH.