B.pl would have to contain valid perl code, and then in your A.pl you could...

eval { require "B.pl"; }
if ($@) {
    # deal with error
}
...
[download]

Cheers!

--
hiseldl
What time is it? It's Camel Time!

The only way to literally include a file is to eval its contents:

eval do { local $/ open my $fh, '<', 'B.pl' or die $!; readline $fh; }
+;
[download]

do FILENAME is great, but many people expect lexicals to be shared, so I only recommend eval STRING for file inclusion now. In my mind, there are two ways of programming with multiple files:

1. Dirty: literal file inclusion. Dirty anyway, so eval STRING is okay;
2. Clean: generalized modules, used as such. No two files use the same package.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

require only loads once and this WILL bite in any persistent environment.

$ echo 'print 1;' > test.pl
$ perl -le'{ local %INC; require "test.pl" } require "test.pl";'
1
1
[download]

Update: that should be local %INC = %INC; in fact.

Makeshifts last the longest.

local %INC;

Good point, but I don't think many people will remember to do that :)

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

There's no need for eval evil or source filter trickery. The simplest method for this is to use perl's own include mechanism.

It's named do 'file;.

included.pl

our %b; @b{'a'..'z'} =  1 .. 26;
[download]

#! perl -slw
use strict;
use Data::Dumper;

do 'included.pl'; ## Perl's include.

our %b;
print Dumper \%b;
[download]

_________
broquaint

See also a related topic Loading a function from another file dynamically?!, which covers almost the same ground, with useful advice.

I did briefly consider using my perl script to mangle the data into C source code and then #include it into my C program. That would certainly make the task easier as I wouldn't have to mess around with databases. However, it would mean that users would have to rebuild the program to update the data, and would also lead to resource "issues". Instead, I did The Right Thing, and my perl script instead spews out a few PDBs using Palm::Raw (which whilst it is listed on CPAN and downloadable through a browser, CPAN.pm didn't want to install for me, but that's irrelevant here). And my C code opens those databases and uses them.

Of course, most of the reasons for me using PDBs are irrelevant to your perl program, but you might like to consider using something like dbm files instead. It seems somehow more elegant :-)