I have no idea how this is happening, but here's some information for you (including some behavior that is a bit surprising to me). First, from perldoc perlvar:

$<*digits*> Contains the subpattern from the corresponding set of capturing parentheses from the last pattern match, not counting patterns matched in nested blocks that have been exited already. (Mnemonic: like \digits.) These variables are all read-only and dynamically scoped to the current BLOCK.

Since the dollar digit variables are auto-localized, I expected that the Exporter code should not have a predefined value of 1. However, I did the following test. First, I created a file called "test.pm":

package test;
foreach ( 1..3 ){
    print "Here: '$1'.\n";
}
1;
[download]

Then, I created a "test.pl" in the same directory:

unshift @INC, '.';
my $var = "abc123def";
$var =~ /(\d+)/;
require test;
[download]

And the output of running it:

Here: '123'.
Here: '123'.
Here: '123'.
[download]

Apparently, the $1 is not auto-localized in a different package. Further, I thought that the foreach loop would have its own scope and be treated as a BLOCK. In fact, even when I explicitly wrapped the loop in braces to create a naked block, $1 was still set to 123.

My theory: you have a regex matching prior to calling the import method that triggers Exporter. In fact, you might even be using the regex in a scalar context yet be taking multiple matches. For instance, this will set $1 to 1:

$var = 'foobar';
$var2 = ( $var =~ /(foo)(bar)/);
print $var2;
[download]

So... perhaps it's a construct similar to the one above that it setting $1 to 1? Do you have any BEGIN blocks or something similar that's triggering this? Somewhere, I think, you have a stray regex that should have the dollar digit variables localized.

Update: Okay, I'm full of it. In rereading what you said:

We would even print $sym so we could see what names it was iterating through - and it was correct. The $sym string would be "$varnameA".

But, if we look at the code in question:

    foreach $sym (@imports) {
        # shortcut for the common case of no type character
        (*{"${callpkg}::$sym"} = \&{"${pkg}::$sym"}, next)
            unless $sym =~ s/^(\W)//;
        $type = $1;
        *{"${callpkg}::$sym"} =
            $type eq '&' ? \&{"${pkg}::$sym"} :
            $type eq '$' ? \${"${pkg}::$sym"} :
            $type eq '@' ? \@{"${pkg}::$sym"} :
            $type eq '%' ? \%{"${pkg}::$sym"} :
            $type eq '*' ?  *{"${pkg}::$sym"} :
            do { require Carp; Carp::croak("Can't export symbol: $type
+$sym") };
    }
[download]

The only way that printing $sym could result in $varnameA is if the substitution failed to recognize the dollar sign as a non-word character:

$var = '$varnameA';
$var =~ s/^(\W)//;
print "Symbol: $1\tVariable: $var\n";
[download]

Resulting in:

Symbol: $    Variable: varnameA
[download]

If $sym really does have the dollar sign left on it, you need to check to see what is screwing up your regular expressions.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

But that's just a random guess - you didn't give me enough to do better than that. Can you reproduce the problem with a simple script? If you can, post it here and I bet we'll find the problem.

-sam

Is there any locale in effect that defines "$" as a \w character?

If not, try adding this at the beginning of the block:

"" =~ /()/;
[download]

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

Two ideas come to my mind:

1. A bug in Perl
2. Someone is replacing Exporter::Heavy::heavy_export() out from under you