In test2.pl, $x is a lexical variable. That means it's only visible within a scope. In this case, since it's not in a block, its scope is the file itself. It will only be visible in nested scopes, never other files.

The easiest way to get this code to work is to use the vars pragma to declare $x as a global variable:

# test1.pl
use strict;
BEGIN { require 'test2.pl' };
print $x;

# test2.pl
use strict;
use vars '$x';
$x = "this is it\n";
[download]

If you're doing something much more complicated, you're better off making a real Perl module and either exporting the variable or making some sort of accessor. The perlmod manpage has some good information.

Well, that worked perfectly in my test code. I also see that using use instead of require and renaming the include file to .pm can eliminate the BEGIN block. Then I tried it out in my application. There is a package that is used by several of the independent daemons, and it also needs the global variables we are "including". When I use use or require in both the daemon and the package it "uses", perl recognizes that the include file has already been "used", and won't use it again, so that either the daemon or the package will fail to include the include file, depending upon the order of the use statements in the daemon. Is there a way around this?

use also calls a class method called import every time it's encountered. You can use Exporter to make variables and functions available to other packages, or you can write your own import routine. I suggest the former.

package My::Constants;
use vars qw( $x $y @EXPORT_OK @ISA );
use strict;
use Exporter ();

@EXPORT_OK = '$x';
@ISA       = 'Exporter';

$x = 'my constant x is a lovable fellow';
$y = 'his ears are green and his belly is yellow';

1;
[download]

It occurs to me that that's a lot of setup code. There's room for a nicer version of Exporter.

You could also so something simpler like keep your constants in a package namespace and refer to them that way from other packages and the main daemon. This reduces clutter in the global namespace and only requires the file to be processed once for all of them.

For example:

#file1.pl
#!/usr/bin/perl -w
use strict;
use Constants;
print "ONE=", $Constants::ONE, "\n";
print "TWO=", $Constants::TWO, "\n";
print "THREE=", $Constants::THREE, "\n";

#Constants.pm
package Constants;
$Constants::ONE = 1;
$Constants::TWO = 2;
1;
[download]

A big problem with this approach is that you don't get compile time checking when you refer to a variable in another package. This is shown above with $Constants::THREE which only causes a problem at run time (at least in Perl 5.6.1).

Even with that drawback, this is a technique I use.

-- Eric Hammond

Since you used the term "#include" I assume you're coming from a C or C++ background where the included file is inserted into the calling file by the pre-processer before the parser gets ahold of it. In those languages it's as if you had typed the second file inside the first so variables declared in the included file would be available in the parent.

In this part of Perl, the language works a bit more like Java and Modula 2. The packages you "require" or "use" have their own scoping which is applied when you use keywords like "my".

The "my" in test2.pl restricts the lexical scope of the $x variable to the enclosing block. In this case, the block is the file test2.pl so the variable $x can only be used inside that file and will not be able to be accessed elsewhere.

It looks like you have reduced a real life problem to the bare essense to elminate any non-contributing factors to studying the problem. In general, this is a great thing as it saves others a lot of time wading through code unrelated to the problem at hand. Unfortunately, it also makes it difficult for me to know what to recommend as a workaround to your problem as I don't know exactly how the data is being used and why you want to share it.

There are options of global variables, "our" variables, package variables with external access, returning values from a function, and probably other ideas folks could come up with. You're probably going to get some recommendations that you not share data at all, but sometimes it's a good thing. It's just difficult to provide an opinoin with the sterilized sample.

I can give you one other hint: The shabang line in test2.pl (#!/usr/bin/perl -w) is unnecessary and, in fact, is ignored when that file is "require"d. It is probably just misleading to the code reader unless test2.pl is actually run as a top level program itself.

There's no special first line needed for Perl packages which are used in a "require" or "use".

-- Eric Hammond

Wow! Two great answers and quickly, even! I have just tried out the method suggested by chromatic, and it works perfectly. Indeed, my background much stronger in c, and other ancient languages than in perl. I so confidently expected to find a #include directive in perl that when I first needed it, I simply put it in, and was surprised that it didn't work!

Oh, yes... My project involves a number of independent perl "daemons" that share a number of common constant values, such as database table names, hence the need for an include file.

Thanks very much for the excellent explanation. I may even be moved to drop something in the collection plate, instead of taking some out as I usually do.

That's the difference between Perl and C!

In Perl you put the common variables and constants in the main program and have the "daemons" access them from there.

CountZero

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

You are running into scoping problems. Defining a lexical with my does not produce a variable which can be seen across file barriers.

If test2.pl contained,

#!/usr/bin/perl -w
use strict;
use vars '$x';
$x="this is it\n";
1;
[download]

A more sophisticated approach would make your test2.pl a .pm and define a namespace with package.

After Compline,
Zaxo

After studying chromatic's sample code, I see why what you propose is not quite sufficient. You need to either have a BEGIN{} block around the "require" or use a "use"--which is very close to a "require" inside a BEGIN.

The reason for this is that the "require" is processed at run time and the $x variable used in test1.pl does not get defined until the test2.pl is compiled. Unfortunately, it never gets to test2.pl because the $x causes an error during the compile of test1.pl.

Putting the "require" in a BEGIN solves this by forcing test2.pl to be compiled (and $x to be declared) before the rest of test1.pl (and the usage of $x).

I have tended to use "use" instead of "require" since it became available in Perl, so didn't think of this problem until seeing chromatic's response.

-- Eric Hammond

#!/usr/bin/perl -w
use strict;

#Imported from other file
our $x;

require 'test2.pl';
print $x;
[download]

#!/usr/bin/perl -w
use strict;
our $x = "this is it\n";
1;
[download]