The low-tech solution would be

# the "variable library", e.g. MyVars.pm

use vars qw($scalar @array %hash);

$scalar = "Foo";
@array = qw(Foo Bar);
%hash = (Foo => "Bar");
1;
[download]

#!/usr/bin/perl -l
use strict;
use warnings;
use MyVars;

print $scalar;
print "@array";
print "$_ => $hash{$_}" for keys %hash;
[download]

The ugly thing is (why I called it low-tech) that you have to mention all variables twice (because of the use vars) — but for "a dozen" variables this should be doable.

use vars qw($scalar @array %hash);
[download]

% perldoc vars

NOTE: For variables in the current package, the functionality provided by this pragma has been superseded by "our" declarations, available in Perl v5.6.0 or later. See "our" in perlfunc.

It's only a few more words to make a proper MyVars module out of it.

package MyVars;
our @ISA = qw(Exporter);
our @EXPORT = qw($scalar @array %hash);

[...]
[download]

... the functionality provided by this pragma has been superseded by "our" declarations ...

The thing is that the extra file implies a separate lexical scope, so you can't use our (without additional hoops), because its effect is lexically scoped.  Even if the docs call use vars "superseded", it still has its occasional uses, because the functionality isn't the same as "our" in every respect.

In the particular case of what the OP wants to use this for (i.e. having some common variable definitions to be included in several scripts), I don't really see an advantage of creating a "proper" module as you call it, i.e. putting the global variables in a different namespace first, only to then alias them all into the current package using Exporter.  As long as there's nothing else in the module, where's the benefit?

Use do rather than require (via use) when the "module" doesn't have a package statement.

It's maybe worth noting that the do would need to be put in a BEGIN block to have it execute at compile time

BEGIN { do "MyVars.pm" }
[download]

And for anyone unsure what the difference is:  in contrast to require, do doesn't keep track of what's already been loaded — which could make a difference if you use MyVars several times (in different namespaces) in the same script/program.

Perfect, my module-foo has never been that good since I'm more of a unix SA who uses perl to do his job, than a perl programmer. Thanks!! http://pastebin.com/QTtvmXzj

The perhaps-even-lower-tech way to go is a "do" statement. Create a file in which you define all your vars (e.g., ".myapprc"):

$foo = "Foo";
@bar = qw/B a r/;
%blah = ( b => 'l', a => 'h' );
[download]

Then, just "load it up" in your script:

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

our($foo, @bar, %blah);
do "xyzrc" or die "xyzrc: $!\n";
[download]

I use this quite a lot, usually with a little more error checking (see "perldoc -f do"), in CGI scripts that need to source external info (database/table names, etc.)

Export those variables from a module.

Eg., have a common module that says something like (untested):

use warnings; use strict;
package Foo::Common;
use Exporter;
push our @ISA, Exporter::;
push our @EXPORT, qw"
        %red %green @blue %yellow
        $brown $purple
";
our %red = ("foo", "bar");
[download]

and then use this module from all other modules by saying

use Foo::Common;
[download]

You can then refer to these variables even if strict is on, as if you have declared them with use vars, only they refer to the respective variables from the common package. It also does not matter whether you set the values of those variables from the common package or some other package, just make sure you don't try to use their values before you initialize them.