You probably want to use our $varname instead, if you really want package variables. See also my our and possibly local (but note that local doesn't do what you might think).

Update: the reason you can "see" the globals using $main::varname is that specifying an explicit package name refers to the package variable whether it's been declared or not. In other words, you're referring to $main::varname, but your lexical $varname isn't the same variable; it just has the same name (but it's not bound to the main package).

For counterpoint, using our is perfect for the OP's task.

By lexically scoping all his wide-scoped package vars, and reducing their visibility to just those places where they are used--prior to splitting the monolithic script into modules--it becomes far easier to identify which variables have to be passed to what subroutines. And that makes the second stage of the process, passing them as parameters, far easier.

As an intermediate step in a refactoring process, lexically scoping the globals is far better than C&Ping the same a huge block of global declarations at the top of every module.

Lexically scope them in the big file first. Make sure everything still works. Split the function into modules--perhaps using the new found knowledge of what routines are dependant upon which globals as an aid to deciding what should go with what--and check again everything still works. Then set about passing those variables through parameters. A totally sane and logical refactoring process.

And for singletons they are perfect too. Even if you do leave them declared at the package scope level.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Actually you probably shouldn't use our, see Why is 'our' good? for my explanation of why I don't like it when you're sharing data between modules.

Well, there are enough cases where package variables are the only thing that works (mostly cases where perl insists on making package vars special). But your complaint isn't about that, exactly. Me, I just use our as a neater replacement for vars (IOW, I practically always just use our at the top of the script - and I prefer it over vars for that just because it looks better).
"What should it profit a man, if he should win a flame war, yet lose his cool?"

The reason is that calling sections of code "components" doesn't actually help you much unless the interfaces between those components are fairly minimal and well-defined. Communicating through random global variables results in complex and poorly defined interfaces.

Oh, and before you go too far in breaking this up you should really look at Exporter. The ability to import functions into a namespace can go a long way towards making this kind of refactoring a lot less painful to do.

ImHO, it's not a very beautiful way for your files to communicate via global variables, especially if they are set by the main script in the main namespace. And the double-colon form is quite error-prone, which is demonstrated by your problem.

I don't know what exactly you are designing, but maybe the best approach would be an OO constructor, like this:

# Pit.pm
package Pit;
use strict;

sub new {
    my ($class, $email) = @_;
    return bless {
        email => $email,
    };
}

sub printIT {
    my $this = shift;
    print '2) ', $this->{email}, "\n";
}

# main script:
use strict;
use Pit;

my $pit = Pit->new('me@example.com');
$pit->printIT;
[download]

By the way, note the capital "P" in the package name, which is the most common and recommended form to write a package name. And note that the package file needs it's own "use strict" because the line from the main script is not effective there. (Same thing with warnings.)

Just one correction: don't bless without $class :-)

sub new {
  my ($self, $email) = @_;
  my $class = ref($self) || $self;
  bless { email => $email }, $class
}
[download]

[]s, HTH, Massa (κς,πμ,πλ)

my $class = ref($self) || $self;

You could throw in another case, just to prevent someone from accidentally calling this method with a $self that happens to evaluate to false:

my $class = ref($self) || $self || __PACKAGE__;

package Gbl;
# simple holds Global data loaded from the config file eventually
use strict;
require  Exporter;
BEGIN{

}

my @ISA = qw(Exporter);
my @EXPORT = qw();
my @EXPORT_OK = qw();

use vars qw(
  $EmailAddr
  $VERSION
);
$VERSION = sprintf "%d.%03d", q$Revision: 1.0 $ =~ /: (\d+)\.(\d+)/;
$EmailAddr = "a\@b.com";

1;
__END__
[download]

$From = "$Gbl::EmailAddr";
....or somewhere else ...
if ($Sender =~  /$Gbl::EmailAddr/) { ...
[download]

Thanks all for the help.