There are basically four ways of declaring a global variable (well, I could some up with some others using soft references, but they're bad juju).

1:  $global::variable;

2:  no strict 'vars';
    $variable;

3:  our $variable;

4:  use vars qw/$variable/;

Of the three, the first should not be encouraged as it's easy to misspell the global and strict won't tell you that. This makes your program more likely to be buggy.

The second is terrible because you lose all benefits of strict, even with lexically scoped variables (misspelling the lexically scoped variable means Perl will think it's a global).

The third is new, as of Perl 5.6. It allows you to declare a lexically scoped global variable. If that sounds confusing, good. If you lexically scope your globals, it can become confusing if you use the same name outside of the scope because then it's easy to misunderstand whether or not something is global.

The "use vars" pragma is the cleanest, IMHO. You can declare it as global, it's not lexically scoped, and when you run across it later in your program, you know it's a global, no questions asked.

All of the above information aside, using global variables can be very dangerous because they are more difficult to manage.

As a side note, the first method is the only one (of the four that I present) that allows you to declare a global in another package. That's might be acceptable if you're exporting a global that a person asks for in their program, but it's usually bad programming to mess with someone else's namespace.

Cheers,
Ovid

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

The document you want isn't at the Monastery, though it was written by our own Dominus. It's called Coping with Scoping.

The short answer to the question I think you're asking is to use vars qw($var).

HTH

use strict;
$global = 1;
[download]

Now there are several ways we can declare variables in Perl, and of course they mean different things.

use vars, and our give globals:

          # globals to our package.
use vars qw/$global1 $global2 $fred/;
our ($global1, $global2, $fred);
[download]

use strict;
package Fred;
our $name = "John";

package Main;
my $name = "Fred";
print $Fred::name;     # prints "John";
print $name;           # prints "Fred";
[download]

use strict;
$::database = "backup";         # global variable in Main

                                # package.
package Fred;
print $::database;              # prints "backup";
[download]

my localizes variables to their block.

#!/usr/local/bin/perl -w
use strict;
my $fred = 3;           # accessible from here to end
                        # of file/package.
{
        my $fred = 2;   # overrides previous $fred until
                        # end of block
        print $fred;    # prints "2";
}
print $fred;            # prints "3"
[download]

use strict;
my @array = qw/this is a sentence/;
{
        local $, = " ";  # changes $, to " ".  Using
                         # "my" with a Perl special
                         # variable generates a compile
                         # time error.
        print @array;    # prints "this is a sentence"
}
print @array;            # prints "thisisasentence"
[download]

use strict;
my $foo = "bar";
local $foo = 2;         # will break.
        # although
{
        local $foo = 2; # will be fine.
}
[download]

The difference between my and local is a subtle one. Local variables exist for that call stack, until the end of the block. So if your block calls subroutines, the localised variable will exist within those subroutines (and any subroutines they call and any they call and so on - which can cause nasty surprises).

Variables declared with my exist _only_ within their block. This means that if the block calls a subroutine that is not defined within the same block, then that subroutine does not automatically get access to the variable (but you can pass it in as an argument).

Excepting these, you cannot access variables declared within a block, at all, from outside that block. That is:

use strict;
package Foo;
my $foo = 12;

package Bar;

print $Foo::foo;        # this won't work
[download]

Phew! I hope that helps.

Jacinta.

(Just a side note)
I think having a package called Main is pure evil. I hope the capital M was a typo :)

2;0 juerd@ouranos:~$ perl -e'undef christmas'
Segmentation fault
2;139 juerd@ouranos:~$
[download]

The following two nodes (and their ensuing threads) may help clarify certain aspects of the differences between my(), our(), local(), and 'use vars': here and here

Many times I find that what people call global is just a file scoped variable. In this case a lexical or constant works fine. I think the biggest mistake made with global variables is not finding out what global means to the questioner.

How do you define "global"? Why do you want to use a global variable? Is this variable to be read-only? Are you passing the variable amongst modules or scripts or just in this one script?

all of your answers were very well put :). The reason for the question (and it is valid in my point of view) is that i have variables being passed through several scripts and subroutines and instead of continuously passing them around and around, i just wanna keep them global. I'm not worried about losing track of my global variables, because i know all of my global variables start with $global_(variablenameinhere) and i do keep all my variables named accordingly with prefixes of what they do or what they're there for.

Even with perl's implementation of 'our' as an internal function, will it still be wiser to use 'use' instead of 'our'?

You really should read the article at this node: 'our' is not 'my', if you haven't already. It specifically addresses your question about whether (or when) to use use or our.

What it perhaps fails to address is the fundamental difference between lexical variables (declared with 'my') and package globals.

Originally, before there were such a thing as lexical variables, ALL variables were [package] globals. Global variables involve underlying constructs called typeglobs, which are basically symbol table elements. One typeglob is created for each unique symbol name in a package, and is shared among various objects with the same name (but different types).

Therefore a package global, $foo shares its typeglob with the package global, @foo, and with the package global, %foo, and with the file handle, foo, ... you get the idea.

There is an entire body of literature describing this, probably far better than I ever could, so I won't go into further detail here (try using Super Search), except to say that a given typeglob contains what may be thought of as "slots" for each kind of thing (variable or handle) that Perl can support. There is a scalar slot, array slot, hash slot, file handle slot, code slot, etc.

For at least scalars, arrays and hashes, the value that goes into the slot is a reference to the appropriate type (or nothing, i.e., undef). So when you take a reference of a package global, using the notation, say, \@arr, what you are doing is simply extracting whatever is in the array slot of the typeglob named 'arr'. The entire typeglob may, itself, be referred to as *arr, should you ever want to do this. Legacy code (i.e., perl4) may contain some typeglob manipulation, since that was pretty much the only way to do several things, such as passing around filehandles.

Which (finally) brings me to lexicals. These have two fundamental differences from package globals. First, they are actually created on the stack (and therefore are destroyed when they go out of scope), and second, they do NOT use typeglobs (which has more subtle implications).

As such, same-named lexical variables of different types do not share symbol table space. They also cannot be manipulated with the typeglob notation (*variable), but they have the distinct advantage of being destroyed upon going out of scope. Some of the power of Perl (such as aliasing variables and whatnot) cannot be used with lexicals. For example, if $main::foo contained the value, 'hello' and if you set \*main::bar = \*main::foo, then $main::bar would thereafter be an alias, indeed another name, for the scalar value referred to by $main::foo (similar to the concept of "hard links" on UNIX filesystems). Changing the value of $main::foo changes the value of $main::foo and vice versa.

So, if you are struggling with the answer to the question, "Should I use a file-scoped lexical or a global?" perhaps understanding the underlying difference between the two may help, somewhat.

dmm

You can give a man a fish and feed him for a day ...
Or, you can teach him to fish and feed him for a lifetime