All it does is, at runtime, temporarily save the value of the global variable, and clear it; and restore it to its old value when the scope is left.

Taking into account that the global variables $a and $b have a special status with regard to strict, because of their connection to sort, and these therefore don't need a declaration, it should be clear to you by now that strict simply complains because you haven't actually declared $aa.

For that purpose, use

use vars qw($aa);
[download]

our $aa;
[download]

my $aa;
[download]

Note that in general it's a big mistake to make $a or $b a lexical variable, because that would mess up their use with sort really good.

For more on the difference between lexical variables and global variables, see perlfaq7: What's the difference between dynamic and lexical (static) scoping? Between local() and my()?

      $a
       $b      Special package variables when using sort(), see
               "sort" in perlfunc.  Because of this specialness
               $a and $b don't need to be declared (using use
               vars, or our()) even when using the "strict
               'vars'" pragma.  Don't lexicalize them with "my
               $a" or "my $b" if you want to be able to use them
               in the sort() comparison block or function.
[download]

I'm surprised nobody has yet posted a link to MJD's excellent Coping with Scoping article. You should give it a read sometime.

While the article is excellent, the question has already been answered :)

the question has already been answered

<rhetorical>So additional information is not wanted?</rhetorical>

My experience at the Monastery says otherwise. I occasionally post "useless" responses like this when I think it could benefit people in the future. Someone finding this thread via supersearch would probably do well to read Coping with Scoping, so that's why I posted a link to it.

One thing that I would like to add is the fact that it's generally a bad idea to allow functions or subs to absorb variables of greater scope by osmosis. If you want test2() to have access to a variable created in test1(), pass it to test2() by reference. If you want test2() to just receive the value, pass by value (instead of reference). But if you can at all avoid it, don't pass implicitly by assuming globals will be there to leak into functions.

There are exceptions, and one exception I can think of is static variables... this for example:

{
    my $static = 10;
    sub test1 {
        print $static++, "\n";
    }
}
test1();
test1();
__OUTPUT__
10
11
[download]

This is a special situation where you actually want to access variables from outside of the sub's internal scope.

use vars qw[ $aa ];
[download]

This is really, really bizarre. I'm using 5.8.1-RC3 in MacOS X 10.3. Here is what I've found:-

If I comment out the lines of test2, then change local $aa =... to local $b = I get no errors. If I change the '$a' assignment to something with 2 letters then I get another error due to that line. I seems as though perl only generates the global symbol error for variables with more than one letter in their name. Very strange.

The obvious way to fix the problem is to do what the error messages are asking for - give a global package name by putting $main::aa

This is not a very good idea though. In general you would be better to pass parameters into the function, and use return values from a function to achieve what you want. Only use global variables as an absolute last resort. (I've never used the 'local' decleration by the way!)

use strict;
test1();

sub test1 {
    test2(1,2);
}

sub test2 {
    my ($a, $aa) = @_;
    print "a = $a\n";
    print "aa = $aa\n";
}
[download]

hhdave, see borisz's response above yours. Basically, $a and $b are on the short list of special variables that are automatically declared by perl, so they already exist in any scope.

As of perl 5.6, you should probably just use my instead of local anyway, but use a variable with meaning to you, not a special one like $a or $b. . .

see my first post ever