May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Perl namespaces, my, our and local variables


Perl Language

Recommended Links Recommended Articles Perl programming environment Debugging Perl for Win32

Perl Warts

Perl Programming Environment Perl as a command line utility tool Perl modules Pipes in Perl Reimplementation of Unix tools      

Namespaces and Modules

grep & map



Tips Beautifiers Humor Etc


The main problem in writing large programs is:

This is a critical part of programming language design and success of OO concept by-and-large was connected with built-in hierarchical namespaces model the OO provides.

One interesting feature of Perl is that unlike other languages it has an explicit concept of namespaces. Each namespace defines a separate symbol table, which is basically a hash with a key for each identifier. In other words in Perl you can have as many user-defined symbol tables as you wish (as many as the number of package statements you use). They are the instrument to segregate code so that one piece of code does not conflict with another.

Each new namespace is defined by package statement. It is active until the next package statement. If there is no package statement all variables belong to namespace main (global namespace).

Namespaces allow you segregate variables and functions into different folders like files in Unix filesystem. In other words they play the role similar to the role of directories in Unix system where full path for the file distinguishes it from the file with the same name but located in different directory. Variables in different namespaces can even have the same name, but they are completely distinct from one another. Namespaces hold only "global" (for a given namespace) variables names, my variables names that have lexical scope of a block are held separately.

A symbol table in Perl is implemented as a hash that holds all of the names defined in a namespace. All of the variable and function names belong to some symbol table (namespace). The hash for each namespace is named after the namespace with two colons. For example, the symbol table for the namespace utils is called %utils::.

That means that you can to access them from your program with regular means of accessing hashes. For example:

DB<3> foreach $s (keys %main::) { print "$s\n"}

If you want to address a variable in other namespace that the current you need to provide "full path" alike addressing Unix files. For example tp access subroutine put_message from namespace utils you need to write:

&utils::put_message("this is warning");

Here we call the function put_message from the namespace utils. In using Unix filesystem terms it would be a file put_message in the directory /utils while in Perl this is symbol put_message in the namespace utils.

In Perl each new namespace is defined by package statement which is a compile time statement as it is influence the construction of symbol table which is compile-time activity.

Main namespace

The main namespace in Perl is called main:: . It is used for all variables as a default if no namespace statement exists. To access variables from all other namespace in the main namespace require qualification with the namespace name if they are accessed outside the scope of package statement which defines this namespace. You can export variable from other named namespaces into main:: so that you can use them without qualification by the namespace name.

The global namespace main:: contains many special variables (such as $_ or %ENV) which are automatically visible from all packages. Some other special variables, such as @INC, $AUTOLOAD, or $a and $b in a sort block also are global in nature and belong to the main namespace by default. @INC and %INC are built-in variables that define the list of directories were library or module will be searched for loading with use or require statements

Non default namespaces. Package statement

Each new namespace with the exception of default (main::) is introduced by package statement. It has just one argument: package name. By convention, package names start with a capital letter, and you should follow that convention when you create your own packages. The scope of a package statement is from the this statement to the next package statement at the same level of nesting or the end of the innermost enclosing block.

The term package is described in "Programming Perl" as:

A quantity of code that values its privacy, and tries to keep other code from trespassing upon its namespace by fencing all of its private belongings (variables and subroutines) into its own area. A variable or subroutine mentioned in the package belongs only to that package, even if there's another variable or subroutine with an identical name in some other package.

All identifiers located with the scope of package declaration belong to the namespace declared in the package statement. They will be placed in the symbol table with this name.

Packages may be nested inside other packages. However, the package name must still be fully qualified. For example, if the package Province is declared inside the package Nation, a variable in the Province package is called as $Nation::Province::var. You cannot use a "relative" package name such as $Province::var within the Nation package for the same thing.

The default main namespace contains all other packages within it.

There is a very readable description of namespaces and typeglobs in Chapter 3 of "Advanced Perl Programming." It is worth reading for no other reason that to understand how Perl keeps track of scalars, arrays, etc. internally. The author uses graphics in his explanations. It also fully explains the difference between dynamic ('local') and lexical ('my') scoping of variables.

You can put a package declaration anywhere you can put a statement. Again, it is very important to understand that this is a compile time statement. You can also switch back into previous namespace in more than one place; package statement merely determines which symbol table is used by the compiler for the rest of that block.

That means that a given namespace can be used in multiple files.

Like Unix directories Perl namespaces are hierarchical and one namespace can be a part of another. The Unix filesystem's tremendous power and flexibility comes from the ability to put files in a multilevel directory tree and then locate them using the directory path. This makes it possible to access ten of thousands files belonging to operating system and various applications. Files with the same name but in different directories can coexist. For example:

The same is true for Perl namespaces. Perl can stores functions and variables inside a complex hierarchy of namespaces too. The above herarchy would be represented in Perl as:

Like directory can store any type of file, namespaces can store any type of variables: scalar, arrays, hashes, functions, etc. The digram '::' serves as the separator between herarchically organized namespaces, just as '/' is the separator in the UNIX world. There are two basic ways to specify the namespace to which a variable belongs:

Like with directories the standard way of referring variables and functions to a particular namespace is to append the namespace to the beginning, using digraph :: as a delimiter, for example,
refers to the function execute in the namespace Global.
refers to the scalar message in the namespace Mail
print keys(%my::important::addresses);
prints out the keys of the hash %addresses in the namespace my::important

You can use the variable "%namespace::" to get a list of all the symbols declared in a given namespace. For example:

foreach $key (keys %Time::) {
   print "\$$key => $Time::{$key}\n"
   print "\@$key => @$Time::{$key}\n";
   print "\%$key => @{[%$Time::{$key}\n"]}\n"; 

Assignment to a typeglob

Assignment to a typeglobis an aliasing operation; that is, *dick = *richard; causes variables, subroutines, formats, and file and directory handles accessible via the identifier richard to also be accessible via the symbol dick . If you want to alias only a particular variable or subroutine, assign a reference instead: *dick = \$richard;

making "constant" scalars

Another use of symbol tables is for making "constant" scalars: *PI = \3.14159265358979; Now you cannot alter $PI , which is probably a good thing, all in all. This isn't the same as a constant subroutine, which is optimized at compile time. A constant subroutine is one prototyped to take no arguments and to return a constant expression; see "Inlining Constant Functions"

The use constant pragma is a convenient shorthand:

use constant PI => 3.14159;

Other options to segregate code in independent semi-isolated parts

In addition to namespaces Perl provides three options for segregating code into independent semi-isolated parts:

If we want to get Perl to read that file and use it as part of our own program, we have three ways of doing this:

Use is now dominant form and all standard modules are included via the use statement.

Review of literature

Perl documentation has man page for package statement.

perlmod -- Perl modules (packages and symbol tables), perlmodlib describes Perl stndard module

In two recommended free books

Useful articles are:

Some useful documents and informative posts are available at the Web sites and PerlMonks



Here's the entry for 'package' in the perlfunc manpage:

    package NAMESPACE
    Declares the compilation unit as being in the given 
    namespace. The scope of the package declaration is from the 
    declaration itself through the end of the enclosing block 
    (the same scope as the local() operator).  All further 
    unqualified dynamic identifiers will be in this namespace.  A 
    package statement affects only dynamic variables--including 
    those you've used local() on--but not lexical variables  
    created with my(). Typically it would be the first 
    declaration in a file to be included by the require or use 
    operator.  You can switch into a package in more than one 
    place; it influences merely which symbol table is used by the 
    compiler for the rest of that block.  You can refer to 
    variables and filehandles in other packages by prefixing the 
    identifier with the package name and a double colon:  
    $Package::Variable.  If the package name is null, the
    main package as assumed.  That is, $::sail is equivalent to

The perl namespaces extension is designed as replacement of the standard means of declaring and importing symbols, such as the pragma use strict 'vars' and Exporter interface for modules. It makes the symbol lookup rules more similar to those in C++ :


The namespace extension is implemented as a special compilation mode. It can be enabled and disabled for each lexical scope, just like use strict. Each package activated during the namespace compilation mode (with the package statement) is treated later as using namespaces, even if other parts of it are compiled in the standard, non-namespace mode. Mixing of both modes in one package is not a very good practice, however, as it could lead to unexpected exceptions caused by undeclared variables.

use namespaces; no namespaces;

Enables or disables the namespaces mode. The setting lasts up to the end of the current lexical scope. Note that the compilation of each source file starts with disabled namespace mode, even if the require or use statement which caused its inclusion lies in the namespace-enabled scope.

Enabling the namespace mode automatically implies no strict 'vars' and vice versa.
use namespaces 'AA', 'BB::CC', ...; 
Enables the namespace mode and sets the import list for all packages defined later in the current lexical scope. This is the analogon of the C++ directive using namespace ... .

The importing relation between packages is transitive. For example, the lookup list for the packages compiled after the statement shown above will consist of AA, the packages imported by AA, BB::CC, the packages imported by BB::CC, BB, and the packages imported by BB. To avoid multiple searches, duplicates in the lookup list are removed immediately.

no namespaces 'AA', 'BB::CC', ...;

Removes the named packages from the current import list, but lets the namespace compilation mode active. Note that this change will affect only packages defined after this statement.

Effects at the run time

Each reference to a variable, both reading and writing, is first checked whether it refers to a declared or imported variable. If not, and the name is unqualified, then a declared variable with this name is looked up in all packages comprising the lookup list, as explained above. If found, the variable is imported into the current package. Otherwise an exception is raised. A qualified variable name is only checked to be pre-declared, if not, an exception is raised as well.

The lookup operation is performed once per variable and package; the declaration check is performed once per variable and each expression (script line) using it which was ever executed. This way the performance penalty is constant and comparable to that of the traditional import mechanism.

Unqualified subroutine calls are resolved in the same manner, but in the case of a failure no special exception is raised, since it will be done by the perl interpreter itself. Taking a subroutine reference \&abc involves the lookup too. There is also a special function namespaces::lookup_sub('package_name', 'sub_name') returning the code reference or undef if the lookup fails.

eval '...' statements, as well as regular expressions with deferred evaluation (like s///e operators or $(?{ }) expressions), re-establish the namespace environment for the duration of the expression compilation.

Top Visited
Past week
Past month


Old News ;-)

[Oct 31, 2015] Coping with Scoping

... ... ...

The problem with Perl isn't that it has no clearly-defined system of name management, but rather that it two systems, both working at once. Here's the Big Secret about Perl variables that most people learn too late: Perl has two completely separate, independent sets of variables. One is left over from Perl 4, and the other is new. The two sets of variables are called `package variables' and `lexical variables', and they have nothing to do with each other.

Package variables came first, so we'll talk about them first. Then we'll see some problems with package variables, and how lexical variables were introduced in Perl 5 to avoid these problems. Finally, we'll see how to get Perl to automatically diagnose places where you might not be getting the variable you meant to get, which can find mistakes before they turn into bugs.

Package Variables
        $x = 1

Here, $x is a package variable. There are two important things to know about package variables:

  1. Package variables are what you get if you don't say otherwise.
  2. Package variables are always global.

Global means that package variables are always visible everywhere in every program. After you do $x = 1, any other part of the program, even some other subroutine defined in some other file, can inspect and modify the value of $x. There's no exception to this; package variables are always global.

Package variables are divided into families, called packages. Every package variable has a name with two parts. The two parts are analogous to the variable's given name and family name. You can call the Vice-President of the United States `Al', if you want, but that's really short for his full name, which is `Al Gore'. Similarly, $x has a full name, which is something like $main::x. The main part is the package qualifier, analogous to the `Gore' part of `Al Gore'. Al Gore and Al Capone are different people even though they're both named `Al'. In the same way, $Gore::Al and $Capone::Al are different variables, and $main::x and $DBI::x are different variables.

You're always allowed to include the package part of the variable's name, and if you do, Perl will know exactly which variable you mean. But for brevity, you usually like to leave the package qualifier off. What happens if you do?

The Current Package

If you just say $x, perl assumes that you mean the variable $x in the current package. What's the current package? It's normally main, but you can change the current package by writing

        package Mypackage;

in your program; from that point on, the current package is Mypackage. The only thing the current package does is affect the interpretation of package variables that you wrote without package names. If the current package is Mypackage, then $x really means $Mypackage::x. If the current package is main, then $x really means $main::x.

If you were writing a module, let's say the MyModule module, you would probably put a line like this at the top of the module file:

        package MyModule;

From there on, all the package variables you used in the module file would be in package MyModule, and you could be pretty sure that those variables wouldn't conflict with the variables in the rest of the program. It wouldn't matter if both you and the author of DBI were to use a variable named $x, because one of those $xes would be $MyModule::x and the other would be $DBI::x.

Remember that package variables are always global. Even if you're not in package DBI, even if you've never heard of package DBI, nothing can stop you from reading from or writing to $DBI::errstr. You don't have to do anything special. $DBI::errstr, like all package variables, is a global variable, and it's available globally; all you have to do is mention its full name to get it. You could even say

        package DBI;
        $errstr = 'Ha ha Tim!';

and that would modify $DBI::errstr.

Package Variable Trivia

There are only three other things to know about package variables, and you might want to skip them on the first reading:

  1. The package with the empty name is the same as main. So $::x is the same as $main::x for any x.
  2. Some variables are always forced to be in package main. For example, if you mention %ENV, Perl assumes that you mean %main::ENV, even if the current package isn't main. If you want %Fred::ENV, you have to say so explicitly, even if the current package is Fred. Other names that are special this way include INC, all the one-punctuation-character names like $_ and $$, @ARGV, and STDIN, STDOUT, and STDERR.
  3. Package names, but not variable names, can contain ::. You can have a variable named $DBD::Oracle::x. This means the variable x in the package DBD::Oracle; it has nothing at all to do with the package DBD which is unrelated. Isaac Newton is not related to Olivia Newton-John, and Newton::Isaac is not related to Newton::John::Olivia. Even though it appears that they both begin with Newton, the appearance is deceptive. Newton::John::Olivia is in package Newton::John, not package Newton.

That's all there is to know about package variables.

Package variables are global, which is dangerous, because you can never be sure that someone else isn't tampering with them behind your back. Up through Perl 4, all variables were package variables, which was worrisome. So Perl 5 added new variables that aren't global.

Lexical Variables

Perl's other set of variables are called lexical variables (we'll see why later) or private variables because they're private. They're also sometimes called my variables because they're always declared with my. It's tempting to call them `local variables', because their effect is confined to a small part of the program, but don't do that, because people might think you're talking about Perl's local operator, which we'll see later. When you want a `local variable', think my, not local.

The declaration

        my $x;

creates a new variable, named x, which is totally inaccessible to most parts of the program---anything outside the block where the variable was declared. This block is called the scope of the variable. If the variable wasn't declared in any block, its scope is from the place it was declared to the end of the file.

You can also declare and initialize a my variable by writing something like

        my $x = 119;

You can declare and initialize several at once:

        my ($x, $y, $z, @args) = (5, 23, @_);

Let's see an example of where some private variables will be useful. Consider this subroutine:

        sub print_report {
          @employee_list = @_;
          foreach $employee (@employee_list) {
            $salary = lookup_salary($employee);
            print_partial_report($employee, $salary);

If lookup_salary happens to also use a variable named $employee, that's going to be the same variable as the one used in print_report, and the works might get gummed up. The two programmers responsible for print_report and lookup_salary will have to coordinate to make sure they don't use the same variables. That's a pain. In fact, in even a medium-sized project, it's an intolerable pain.

The solution: Use my variables:

        sub print_report {
          my @employee_list = @_;
          foreach my $employee (@employee_list) {
            my $salary = lookup_salary($employee);
            print_partial_report($employee, $salary);

my @employee_list creates a new array variable which is totally inaccessible outside the print_report function. for my $employee creates a new scalar variable which is totally inaccessible outside the foreach loop, as does my $salary. You don't have to worry that the other functions in the program are tampering with these variables, because they can't; they don't know where to find them, because the names have different meanings outside the scope of the my declarations. These `my variables' are sometimes called `lexical' because their scope depends only on the program text itself, and not on details of execution, such as what gets executed in what order. You can determine the scope by inspecting the source code without knowing what it does. Whenever you see a variable, look for a my declaration higher up in the same block. If you find one, you can be sure that the variable is inaccessible outside that block. If you don't find a declaration in the smallest block, look at the next larger block that contains it, and so on, until you do find one. If there is no my declaration anywhere, then the variable is a package variable.

my variables are not package variables. They're not part of a package, and they don't have package qualifiers. The current package has no effect on the way they're interpreted. Here's an example:

        my $x = 17;

        package A;
        $x = 12;

        package B;
        $x = 20;

        # $x is now 20.
        # $A::x and $B::x are still undefined

The declaration my $x = 17 at the top creates a new lexical variable named x whose scope continues to the end of the file. This new meaning of $x overrides the default meaning, which was that $x meant the package variable $x in the current package.

package A changes the current package, but because $x refers to the lexical variable, not to the package variable, $x=12 doesn't have any effect on $A::x. Similarly, after package B, $x=20 modifies the lexical variable, and not any of the package variables.

At the end of the file, the lexical variable $x holds 20, and the package variables $main::x, $A::x, and $B::x are still undefined. If you had wanted them, you could still have accessed them by using their full names.

The maxim you must remember is:

Package variables are global variables.
For private variables, you must use my.

local and my

Almost everyone already knows that there's a local function that has something to do with local variables. What is it, and how does it related to my? The answer is simple, but bizarre:

my creates a local variable. local doesn't.

First, here's what local $x really does: It saves the current value of the package variable $x in a safe place, and replaces it with a new value, or with undef if no new value was specified. It also arranges for the old value to be restored when control leaves the current block. The variables that it affects are package variables, which get local values. But package variables are always global, and a local package variable is no exception. To see the difference, try this:

        $lo = 'global';
        $m  = 'global';

        sub A {
          local $lo = 'AAA';
          my    $m  = 'AAA';

        sub B {
          print "B ", ($lo eq 'AAA' ? 'can' : 'cannot') ,
                " see the value of lo set by A.\n";

          print "B ", ($m  eq 'AAA' ? 'can' : 'cannot') ,
                " see the value of m  set by A.\n";

This prints

        B can see the value of lo set by A.
        B cannot see the value of m  set by A.

What happened here? The local declaration in A saved a new temporary value, AAA, in the package variable $lo. The old value, global, will be restored when A returns, but before that happens, A calls B. B has no problem accessing the contents of $lo, because $lo is a package variable and package variables are always available everywhere, and so it sees the value AAA set by A.

In contrast, the my declaration created a new, lexically scoped variable named $m, which is only visible inside of function A. Outside of A, $m retains its old meaning: It refers the the package variable $m; which is still set to global. This is the variable that B sees. It doesn't see the AAA because the variable with that value is a lexical variable, and only exists inside of A.

What Good is local?

Because local does not actually create local variables, it is not very much use. If, in the example above, B happened to modify the value of $lo, then the value set by A would be overwritten. That is exactly what we don't want to happen. We want each function to have its own variables that are untouchable by the others. This is what my does.

Why have local at all? The answer is 90% history. Early versions of Perl only had global variables. local was very easy to implement, and was added to Perl 4 as a partial solution to the local variable problem. Later, in Perl 5, more work was done, and real local variables were put into the language. But the name local was already taken, so the new feature was invoked with the word my. my was chosen because it suggests privacy, and also because it's very short; the shortness is supposed to encourage you to use it instead of local. my is also faster than local.

When to Use my and When to Use local

Always use my; never use local.

Wasn't that easy?

Other Properties of my Variables

Every time control reaches a my declaration, Perl creates a new, fresh variable. For example, this code prints x=1 fifty times:

        for (1 .. 50) {
          my $x;
          print "x=$x\n";

You get a new $x, initialized to undef, every time through the loop.

If the declaration were outside the loop, control would only pass by it once, so there would only be one variable:

        { my $x;
          for (1 .. 50) {
            print "x=$x\n";

This prints x=1, x=2, x=3, ... x=50.

You can use this to play a useful trick. Suppose you have a function that needs to remember a value from one call to the next. For example, consider a random number generator. A typical random number generator (like Perl's rand function) has a seed in it. The seed is just a number. When you ask the random number generator for a random number, the function performs some arithmetic operation that scrambles the seed, and it returns the result. It also saves the result and uses it as the seed for the next time it is called.

Here's typical code: (I stole it from the ANSI C standard, but it behaves poorly, so don't use it for anything important.)

        $seed = 1;
        sub my_rand {
          $seed = int(($seed * 1103515245 + 12345) / 65536) % 32768;
          return $seed;

And typical output:


There's a problem here, which is that $seed is a global variable, and that means we have to worry that someone might inadvertently tamper with it. Or they might tamper with it on purpose, which could affect the rest of the program. What if the function were used in a gambling program, and someone tampered with the random number generator?

But we can't declare $seed as a my variable in the function:

        sub my_rand {
          my $seed;
          $seed = int(($seed * 1103515245 + 12345) / 65536) % 32768;
          return $seed;

If we did, it would be initialized to undef every time we called my_rand. We need it to retain its value between calls to my_rand.

Here's the solution:

        { my $seed = 1;
          sub my_rand {
            $seed = int(($seed * 1103515245 + 12345) / 65536) % 32768;
            return $seed;

The declaration is outside the function, so it only happens once, at the time the program is compiled, not every time the function is called. But it's a my variable, and it's in a block, so it's only accessible to code inside the block. my_rand is the only other thing in the block, so the $seed variable is only accessible to the my_rand function.

$seed here is sometimes called a `static' variable, because it stays the same in between calls to the function. (And because there's a similar feature in the C language that is activated by the static keyword.)

my Variable Trivia
  1. You can't declare a variable my if its name is a punctuation character, like $_, @_, or $$. You can't declare the backreference variables $1, $2, ... as my. The authors of my thought that that would be too confusing.
  2. Obviously, you can't say my $DBI::errstr, because that's contradictory---it says that the package variable $DBI::errstr is now a lexical variable. But you can say local $DBI::errstr; it saves the current value of $DBI::errstr and arranges for it to be restored at the end of the block.
  3. New in Perl 5.004, you can write

            foreach my $i (@list) {

    instead, to confine the $i to the scope of the loop instead. Similarly,

            for (my $i=0; $i<100; $i++) { 

    confines the scope of $i to the for loop.


If you're writing a function, and you want it to have private variables, you need to declare the variables with my. What happens if you forget?

        sub function {
          $x = 42;        # Oops, should have been my $x = 42.

In this case, your function modifies the global package variable $x. If you were using that variable for something else, it could be a disaster for your program.

Recent versions of Perl have an optional protection against this that you can enable if you want. If you put

        use strict 'vars';

at the top of your program, Perl will require that package variables have an explicit package qualifier. The $x in $x=42 has no such qualifier, so the program won't even compile; instead, the compiler will abort and deliver this error message:

        Global symbol "$x" requires explicit package name at ...

If you wanted $x to be a private my variable, you can go back and add the my. If you really wanted to use the global package variable, you could go back and change it to

        $main::x = 42;

or whatever would be appropriate.

Just saying use strict turns on strict vars, and several other checks besides. See perldoc strict for more details.

Now suppose you're writing the Algorithms::KnuthBendix modules, and you want the protections of strict vars But you're afraid that you won't be able to finish the module because your fingers are starting to fall off from typing $Algorithms::KnuthBendix::Error all the time.

You can save your fingers and tell strict vars to make an exception:

        package Algorithms::KnuthBendix;
        use vars '$Error';

This exempts the package variable $Algorithms::KnuthBendix::Error from causing a strict vars failure if you refer to it by its short name, $Error.

You can also turn strict vars off for the scope of one block by writing

        { no strict 'vars';

          # strict vars is off for the rest of the block.



Package variables are always global. They have a name and a package qualifier. You can omit the package qualifier, in which case Perl uses a default, which you can set with the package declaration. For private variables, use my. Don't use local; it's obsolete.

You should avoid using global variables because it can be hard to be sure that no two parts of the program are using one another's variables by mistake.

To avoid using global variables by accident, add use strict 'vars' to your program. It checks to make sure that all variables are either declared private, are explicitly qualified with package qualifiers, or are explicitly declared with use vars.

  1. The tech editors complained about my maxim `Never use local.' But 97% of the time, the maxim is exactly right. local has a few uses, but only a few, and they don't come up too often, so I left them out, because the whole point of a tutorial article is to present 97% of the utility in 50% of the space.

    I was still afraid I'd get a lot of tiresome email from people saying ``You forgot to mention that local can be used for such-and-so, you know.'' So in the colophon at the end of the article, I threatened to deliver Seven Useful Uses for local in three months. I mostly said it to get people off my back about local. But it turned out that I did write it, and it was published some time later.

    The Seven Useful Uses of local is now available on the web site. It appeared in The Perl Journal issue #14.

  2. Here's another potentially interesting matter that I left out for space and clarity. I got email from Robert Watkins with a program he was writing that didn't work. The essence of the bug looked like this:
            my $x;
            for $x (1..5) {
            sub s { print "$x, " }

    Robert wanted this to print 1, 2, 3, 4, 5, but it did not. Instead, it printed , , , , , . Where did the values of $x go?

    The deal here is that normally, when you write something like this:

                        for $x (...) { }

    Perl wants to confine the value of the index variable to inside the loop. If $x is a package variable, it pretends that you wrote this instead:

            { local $x; for $x (...) { } }

    But if $x is a lexical variable, it pretends you wrote this instead, instead:

            { my $x;    for $x (...) { } }

    This means that the loop index variable won't get propagated to subroutines, even if they're in the scope of the original declaration.

    I probably shouldn't have gone on at such length, because the perlsyn manual page describes it pretty well:

    ...the variable is implicitly local to the loop and regains its former value upon exiting the loop. If the variable was previously declared with my, it uses that variable instead of the global one, but it's still localized to the loop. (Note that a lexically scoped variable can cause problems if you have subroutine or format declarations within the loop which refer to it.)

    In my opinion, lexically scoping the index variable was probably a mistake. If you had wanted that, you would have written for my $x ... in the first place. What I would have liked it to do was to localize the lexical variable: It could save the value of the lexical variable before the loop, and restore it again afterwards. But there may be technical reasons why that couldn't be done, because this doesn't work either:

    	my $m;
    	{ local $m = 12;

    The local fails with this error message:

    	Can't localize lexical variable $m...

    There's been talk on P5P about making this work, but I gather it's not trivial.

  3. Added 2000-01-05: Perl 5.6.0 introduced a new our(...) declaration. Its syntax is the same as for my(), and it is a replacement for use vars.

    Without getting into the details, our() is just like use vars; its only effect is to declare variables so that they are exempt from the strict 'vars' checking. It has two possible advantages over use vars, however: Its syntax is less weird, and its effect is lexical. That is, the exception that it creates to the strict checking continues only to the end of the current block:

            use strict 'vars';
              $x = 1;   # Use of global variable $x here is OK
            $x = 2;     # Use of $x here is a compile-time error as usual

    So whereas use vars '$x' declares that it is OK to use the global variable $x everywhere, our($x) allows you to say that global $x should be permitted only in certain parts of your program, and should still be flagged as an error if you accidentally use it elsewhere.

  4. Added 2000-01-05: Here's a little wart that takes people by surprise. Consider the following program:
            use strict 'vars';
            my @lines = <>;
            my @sorted = sort backwards @lines;
            print @sorted;
            sub backwards { $b cmp $a }

    Here we have not declared $a or $b, so they are global variables. In fact, they have to be global, because the sort operator must to be able to set them up for the backwards function. Why doesn't strict produce a failure?

    The variables $a and $b are exempted from strict vars checking, for exactly this reason.

'our' is not 'my'

Update: At the request of a couple of people, some as replies to this node and one as a private message, I have added a link to this node from the Tutorials section. I have linked it rather than repost it to tutorials as there is no reason for me to get the rep twice. I might add that I would not have done this were it not for the high rep this node has received (thus suggesting to me that monks find this information useful).

Many people misunderstand how our is used and I've often seen code where it's used as a synonym for my. This is not the case and I hope this clears up some of the differences. I'm posting this because I've run across this a few times lately and I thought I should just 'get it out there' for others.

There are basically two ways of declaring variables in Perl: global and lexical. A global variable has a package name prepending to it:

$main::foo; $CGI::POST_MAX; @foo::bar;


All packages can access the variable $foo in the main symbol table (%main:: or the shorthand %::) by using $main::foo. Global variables are generally a bad idea, but do crop up in a lot of code.

A lexically scoped variable is declared with my:

my $foo; my $POST_MAX; my @bar;


Though they look similar to the package variables above, they are not the same and cannot be accessed outside of the scope in which they were declared.

If you use strict and you try to access a variable that's not previously declared, you'll get an error similar to the following:

Global symbol "$foo" requires explicit package name at C:\ +line 2.


Basically, Perl expects that you are trying to use a package variable, but left off the package name. The problem with using package names ($main::foo) is that strict ignores these variables and if you type $main::field in one place and $main::feild in another place, strict won't warn you of the typo.

our tries to help out by letting you use package variables without adding the package name. The following two variables are the same:

package foo; use strict; our $bar; # These are the same $foo::bar; # These are the same


That eliminates the $main::f(ie|ei)ld problem by allowing you to do this:

our $field;


From there, you just drop package names and the script will run and later Perl will kill the script if you try use $feild. Unfortunately, there are a lot of problems with this.

The main problem is that you are now using global variables which is generally a Bad Thing. Any code, anywhere, can change your global. Large systems with lots of globals typically suffer this problems and quickly become unmaintainable.

This also leads to very subtle coding errors. Try the following code:

use strict; for ( 1 .. 3 ) { &doit } sub doit { our $foo; print ++$foo . "\n"; }


That will print 1, 2, and 3 on successive lines. Change the our to a my and it prints 1, 1, and 1. Because the my variable goes out of scope at the end of the sub and the our variable doesn't (since it's global), you get wildly different results.

There is one use I have found for our variables. if I am forced to maintain a large code base with lots of global variables, I usually expect to see lots of code problems, including misspellings of those globals that are overlooked due to the hacked nature of those code. For example, one site I worked on had some object-oriented code that stuffs a lot of data into package main (you can keep reading after you stop laughing). I've seen code like this:

$main::sql = $order->lineItemSQL; $main::dbh->prepare( $main::sql );



I know, it doesn't make a lot of sense (why doesn't it just return the line items instead of the SQL?), but I needed to clean up stuff like that. So, in my code, I put the following:

our ( $sql, $dbh ); #later $sql = $order->lineItemSQL; $dbh->prepare( $sql );



I didn't convert them to my variables because these variables were being declared in another package.

This doesn't seem like much benefit aside from eliminating a few bytes (and it certainly wasn't the best solution, but we've all had time constraints...). However, there is a huge benefit. Later in the code, when we encounter $main::slq, it becomes $slq and the program dies a much needed death.

As a side note: the primary difference (that I can see) between our and use vars appears to be that our lexically scopes the use of the variable name (not the variable) and the other does not. The following code snippets should clarify that:

use strict; { use vars qw/ $foo /; $foo = "Ovid"; } print $foo;



That code will work fine. However, change the use vars qw/ $foo /; to our $foo and Perl dies, telling you that $foo requires an explicit package name. However, change the print statement to include the package name and all is well:

use strict; { our $foo; $foo = "Ovid"; } print $main::foo;



This behavior may not seem immediately useful, but you can then use an our declaration at the top of a subroutine, strip off the package names in the sub, and not worry about this conflicting with my variables in the rest of the code.

use strict; my $foo = 'bar'; &baz; sub baz { our $foo = 7; print $foo; } print $foo;



Change that code to use "use vars" and you'll see it print 7 twice, stepping on your my variable.

Interesting to note that the only uses I've found for our have been hacking bad code...


Scope of variables in Perl

There are two major variable types in Perl. One of them is the package global variable declared either with the now obsolete use vars construct or with our.

The other one is the lexical variable declared with my.

Let's see what happens when you declare a variable using my? In which parts of the code will that variable be visible? In other words, what is the scope of the variable?

  1. #!/usr/bin/perl
  2. use strict;
  3. use warnings;
  4. {
  5. my $email = '';
  6. print "$email\n"; #
  7. }
  8. # print $email;
  9. # $email does not exists
  10. # Global symbol "$email" requires explicit package name at ...

Inside the anonymous block (the pair of curly braces {}), first we see the declaration of a new variable called $email. This variable exists between the point of its declaration till the end of the block. Thus the line after the closing curly brace } had to be commented out. If you removed the # from the # print $email; line, and tried to run the script, you'd get the following compile-time error: Global symbol "$email" requires explicit package name at ....

In other words, the scope of every variable declared with my is the enclosing block..

Variable scope: visible everywhere

The variable $lname is declared at the beginning of the code. It will be visible till the end of the file everywhere. Even inside blocks. Even if those are function declarations. If we change the variable inside the block, that will change the value for the rest of the code. Even when you leave the block:

  1. #!/usr/bin/perl
  2. use strict;
  3. use warnings;
  4. my $lname = "Bar";
  5. print "$lname\n"; # Bar
  6. {
  7. print "$lname\n"; # Bar
  8. $lname = "Other";
  9. print "$lname\n"; # Other
  10. }
  11. print "$lname\n"; # Other

Variable hidden by other declaration

  1. #!/usr/bin/perl
  2. use strict;
  3. use warnings;
  4. my $fname = "Foo";
  5. print "$fname\n"; # Foo
  6. {
  7. print "$fname\n"; # Foo
  8. my $fname = "Other";
  9. print "$fname\n"; # Other
  10. }
  11. print "$fname\n"; # Foo

In this case the variable $fname is declared at the beginning of the code. As written earlier, it will be visible till the end of the file everywhere, except in places where they are hidden by locally declared variables with the same name.

Inside the block we used my to declare another variable with the same name. This will effectively hide the $fname declared outside the block till we leave the block. At the end of the block (at the closing }), the $fname declared inside will be destroyed and the original $fname will be accessible again. This feature is especially important as this makes it easy to create variables inside small scopes without the need to think about possible use of the same name outside.

Same name in multiple blocks

You can freely use the same variable name in multiple block. These variables have no connection to each other.

  1. #!/usr/bin/perl
  2. use strict;
  3. use warnings;
  4. {
  5. my $name = "Foo";
  6. print "$name\n"; # Foo
  7. }
  8. {
  9. my $name = "Other";
  10. print "$name\n"; # Other
  11. }

In-file package declaration

This a bit more advanced example, but it might be important to mention it here:

Perl allows us to switch between name-spaces using the package keyword inside a file. A package declaration does NOT provide scope. If you declare a variable in the implicit main package which is just the regular body of your script, that $fname variable will be visible even in other name-spaces in the same file.

If you declare a variable called $lname in the 'Other' name-space, it will be visible when later you might switch back to the main name-space. If the package Other declaration was in another file, then the variables would have separate scope created by the file.

  1. #!/usr/bin/perl
  2. use strict;
  3. use warnings;
  4. my $fname = "Foo";
  5. print "$fname\n"; # Foo
  6. package Other;
  7. use strict;
  8. use warnings;
  9. print "$fname\n"; # Foo
  10. my $lname = 'Bar';
  11. print "$lname\n"; # Bar
  12. package main;
  13. print "$fname\n"; # Foo
  14. print "$lname\n"; # Bar

Recommended Links


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last updated: September 12, 2017