What is the difference between my and local in Perl? - perl

I am seeing both of them used in this script I am trying to debug and the literature is just not clear. Can someone demystify this for me?

The short answer is that my marks a variable as private in a lexical scope, and local marks a variable as private in a dynamic scope.
It's easier to understand my, since that creates a local variable in the usual sense. There is a new variable created and it's accessible only within the enclosing lexical block, which is usually marked by curly braces. There are some exceptions to the curly-brace rule, such as:
foreach my $x (#foo) { print "$x\n"; }
But that's just Perl doing what you mean. Normally you have something like this:
sub Foo {
my $x = shift;
print "$x\n";
}
In that case, $x is private to the subroutine and its scope is enclosed by the curly braces. The thing to note, and this is the contrast to local, is that the scope of a my variable is defined with respect to your code as it is written in the file. It's a compile-time phenomenon.
To understand local, you need to think in terms of the calling stack of your program as it is running. When a variable is local, it is redefined from the point at which the local statement executes for everything below that on the stack, until you return back up the stack to the caller of the block containing the local.
This can be confusing at first, so consider the following example.
sub foo { print "$x\n"; }
sub bar { local $x; $x = 2; foo(); }
$x = 1;
foo(); # prints '1'
bar(); # prints '2' because $x was localed in bar
foo(); # prints '1' again because local from foo is no longer in effect
When foo is called the first time, it sees the global value of $x which is 1. When bar is called and local $x runs, that redefines the global $x on the stack. Now when foo is called from bar, it sees the new value of 2 for $x. So far that isn't very special, because the same thing would have happened without the call to local. The magic is that when bar returns we exit the dynamic scope created by local $x and the previous global $x comes back into scope. So for the final call of foo, $x is 1.
You will almost always want to use my, since that gives you the local variable you're looking for. Once in a blue moon, local is really handy to do cool things.

Dynamic Scoping. It is a neat concept. Many people don't use it, or understand it.
Basically think of my as creating and anchoring a variable to one block of {}, A.K.A. scope.
my $foo if (true); # $foo lives and dies within the if statement.
So a my variable is what you are used to. whereas with dynamic scoping $var can be declared anywhere and used anywhere.
So with local you basically suspend the use of that global variable, and use a "local value" to work with it. So local creates a temporary scope for a temporary variable.
$var = 4;
print $var, "\n";
&hello;
print $var, "\n";
# subroutines
sub hello {
local $var = 10;
print $var, "\n";
&gogo; # calling subroutine gogo
print $var, "\n";
}
sub gogo {
$var ++;
}
This should print:
4
10
11
4

Quoting from Learning Perl:
But local is misnamed, or at least misleadingly named. Our friend Chip Salzenberg says that if he ever gets a chance to go back in a time machine to 1986 and give Larry one piece of advice, he'd tell Larry to call local by the name "save" instead.[14] That's because local actually will save the given global variable's value away, so it will later automatically be restored to the global variable. (That's right: these so-called "local" variables are actually globals!) This save-and-restore mechanism is the same one we've already seen twice now, in the control variable of a foreach loop, and in the #_ array of subroutine parameters.
So, local saves a global variable's current value and then set it to some form of empty value. You'll often see it used to slurp an entire file, rather than leading just a line:
my $file_content;
{
local $/;
open IN, "foo.txt";
$file_content = <IN>;
}
Calling local $/ sets the input record separator (the value that Perl stops reading a "line" at) to an empty value, causing the spaceship operator to read the entire file, so it never hits the input record separator.

I can’t believe no one has linked to Mark Jason Dominus’ exhaustive treatises on the matter:
Coping with Scoping
And afterwards, if you want to know what local is good for after all,Seven Useful Uses of local

http://perldoc.perl.org/perlsub.html#Private-Variables-via-my()
Unlike dynamic variables created by
the local operator, lexical variables
declared with my are totally hidden
from the outside world, including any
called subroutines. This is true if
it's the same subroutine called from
itself or elsewhere--every call gets
its own copy.
http://perldoc.perl.org/perlsub.html#Temporary-Values-via-local()
A local modifies its listed variables
to be "local" to the enclosing block,
eval, or do FILE --and to any
subroutine called from within that
block. A local just gives temporary
values to global (meaning package)
variables. It does not create a local
variable. This is known as dynamic
scoping. Lexical scoping is done with
my, which works more like C's auto
declarations.
I don't think this is at all unclear, other than to say that by "local to the enclosing block", what it means is that the original value is restored when the block is exited.

Well Google really works for you on this one: http://www.perlmonks.org/?node_id=94007
From the link:
Quick summary: 'my' creates a new
variable, 'local' temporarily amends
the value of a variable.
ie, 'local' temporarily changes the
value of the variable, but only
within the scope it exists in.
Generally use my, it's faster and doesn't do anything kind of weird.

From man perlsub:
Unlike dynamic variables created by the local operator, lexical variables declared with my are totally hidden from the outside world, including any called subroutines.
So, oversimplifying, my makes your variable visible only where it's declared. local makes it visible down the call stack too. You will usually want to use my instead of local.

Your confusion is understandable. Lexical scoping is fairly easy to understand but dynamic scoping is an unusual concept. The situation is made worse by the names my and local being somewhat inaccurate (or at least unintuitive) for historical reasons.
my declares a lexical variable -- one that is visible from the point of declaration until the end of the enclosing block (or file). It is completely independent from any other variables with the same name in the rest of the program. It is private to that block.
local, on the other hand, declares a temporary change to the value of a global variable. The change ends at the end of the enclosing scope, but the variable -- being global -- is visible anywhere in the program.
As a rule of thumb, use my to declare your own variables and local to control the impact of changes to Perl's built-in variables.
For a more thorough description see Mark Jason Dominus' article Coping with Scoping.

local is an older method of localization, from the times when Perl had only dynamic scoping. Lexical scoping is much more natural for the programmer and much safer in many situations. my variables belong to the scope (block, package, or file) in which they are declared.
local variables instead actually belong to a global namespace. If you refer to a variable $x with local, you are actually referring to $main::x, which is a global variable. Contrary to what it's name implies, all local does is push a new value onto a stack of values for $main::x until the end of this block, at which time the old value will be restored. That's a useful feature in and of itself, but it's not a good way to have local variables for a host of reasons (think what happens when you have threads! and think what happens when you call a routine that genuinely wants to use a global that you have localized!). However, it was the only way to have variables that looked like local variables back in the bad old days before Perl 5. We're still stuck with it.

"my" variables are visible in the current code block only. "local" variables are also visible where ever they were visible before. For example, if you say "my $x;" and call a sub-function, it cannot see that variable $x. But if you say "local $/;" (to null out the value of the record separator) then you change the way reading from files works in any functions you call.
In practice, you almost always want "my", not "local".

Look at the following code and its output to understand the difference.
our $name = "Abhishek";
sub sub1
{
print "\nName = $name\n";
local $name = "Abhijeet";
&sub2;
&sub3;
}
sub sub2
{
print "\nName = $name\n";
}
sub sub3
{
my $name = "Abhinav";
print "\nName = $name\n";
}
&sub1;
Output is :
Name = Abhishek
Name = Abhijeet
Name = Abhinav

&s;
sub s()
{
local $s="5";
&b;
print $s;
}
sub b()
{
$s++;
}
The above script prints 6.
But if we change local to my it will print 5.
This is the difference. Simple.

It will differ only when you have a subroutine called within a subroutine, for example:
sub foo {
print "$x\n";
}
sub bar { my $x; $x = 2; foo(); }
bar();
It prints nothing as $x is limited by {} of bar and not visible to called subroutines, for example:
sub foo { print "$x\n"; }
sub bar { local $x; $x = 2; foo(); }
bar();
It will print 2 as local variables are visible to called subroutines.

dinomite's example of using local to redefine the record delimiter is the only time I have ran across in a lot of perl programming. I live in a niche perl environment [security programming], but it really is a rarely used scope in my experience.

I think the easiest way to remember it is this way. MY creates a new variable. LOCAL temporarily changes the value of an existing variable.

#!/usr/bin/perl
sub foo { print ", x is $x\n"; }
sub testdefault { $x++; foo(); } # prints 2
sub testmy { my $x; $x++; foo(); } # prints 1
sub testlocal { local $x = 2; foo(); } # prints 2. new set mandatory
print "Default, everything is global";
$x = 1;
testdefault();
print "My does not affect function calls outside";
$x = 1;
testmy();
print "local is everything after this but initializes a new";
$x = 1;
testlocal();
As mentioned in testlocal comment, declaring "local $x;" means that $x is now undef

Related

Can variable declarations be placed in a common script

Before I start, the whole 'concept' may be technically impossible; hopefully someone will have more knowledge about such things, and advise me.
With Perl, you can "declare" global variables at the start of a script via my / our thus:
my ($a,$b,$c ..)
That's fine with a few unique variables. But I am using about 50 of them ... and the same names (not values) are used by five scripts. Rather than having to place huge my( ...) blocks at the start of each file, I'm wondering if there is a way to create them in one script. Note: Declare the namespace, not their values.
I have tried placing them all in a single file, with the shebang at the top, and a 1 at the bottom, and then tried "require", "use" and "do" to load them in. But - at certain times -the script complains it cannot find the global package name. (Maybe the "paths.pl" is setting up the global space relative to itself - which cannot be 'seen' by the other scripts)
Looking on Google, somebody suggested setting variables in the second file, and still setting the my in the calling script ... but that is defeating the object of what I'm trying to do, which is simply declare the name space once, and setting the values in another script
** So far, it seems if I go from a link in an HTML page to a perl script, the above method works. But when I call a script via XHTMLRequest using a similar setup, it cannot find the $a, $b, $c etc within the "paths" script
HTML
<form method="post" action="/cgi-bin/track/script1.pl>
<input type="submit" value="send"></form>
Perl: (script1.pl)
#shebang
require "./paths.pl"
$a=1;
$b="test";
print "content-type: text/html\n\n";
print "$a $b";
Paths.pl
our($a,
$b,
$c ...
)1;
Seems to work OK, with no errors. But ...
# Shebang
require "./paths.pl"
XHTMLREQUEST script1.pl
Now it complains it cannot find $a or $b etc as an "explicit package" for "script1.pl"
Am I moving into the territory of "modules" - of which I know little. Please bear in mind, I am NOT declaring values within the linked file, but rather setting up the 'global space' so that they can be used by all scripts which declare their own values.
(On a tangent, I thought - in the past - a file in the same directory could be accessed as "paths.pl" -but it won't accept that, and it insists on "./" Maybe this is part of the problem. I have tried absolute and relative paths too, from "url/cgi-bin/track/" to "/cgi-bin/track" but can't seem to get that to work either)
I'm fairly certain it's finding the paths file as I placed a "my value" before the require, and set a string within paths, and it was able to print it out.
First, lexical (my) variables only exist in their scope. A file is a scope, so they only exist in their file. You are now trying to work around that, and when you find yourself fighting the language that way, you should realize that you are doing it wrong.
You should move away from declaring all variables in one go at the top of a program. Declare them near the scope you want to use them, and declare them in the smallest scope possible.
You say that you want to "Set up a global space", so I think you might misunderstand something. If you want to declare a lexical variable in some scope, you just do it. You don't have to do anything else to make that possible.
Instead of this:
my( $foo, $bar, $baz );
$foo = 5;
sub do_it { $bar = 9; ... }
while( ... ) { $baz = 6; ... }
Declare the variable just where you want them:
my $foo = 5;
sub do_it { my $bar = 9; ... }
while( ... ) { my $baz = 6; ... }
Every lexical variable should exist in the smallest scope that can tolerate it. That way nothing else can mess with it and it doesn't retain values from previous operations when it shouldn't. That's the point of them, after all.
When you declare them to be file scoped, then don't declare them in the scope that uses them, you might have two unrelated uses of the same name conflicting with each other. One of the main benefits of lexical variables is that you don't have to know the names of any other variables in scope or in the program:
my( $foo, ... );
while( ... ) {
$foo = ...;
do_something();
...
}
sub do_something {
$foo = ...;
}
Are those uses of $foo in the while and the sub the same, or do they accidentally have the same name? That's a cruel question to leave up to the maintenance program.
If they are the same thing, make the subroutine get its value from its argument list instead. You can use the same names, but since each scope has it's own lexical variables, they don't interfere with each other:
while( ... ) {
my $foo = ...;
do_something($foo);
...
}
sub do_something {
my( $foo ) = #_;
}
See also:
How to share/export a global variable between two different perl scripts?
You say you aren't doing what I'm about to explain, but other people may want to do something similar to share values. Since you are sharing the same variable names across programs, I suspect that this is actually what it going on, though.
In that case, there are many modules on CPAN that can do that job. What you choose depends on what sort of stuff you are trying to share between programs. I have a chapter in Mastering Perl all about it.
You might be able to get away with something like this, where one module defines all the values and makes them available for export:
# in Local/Config.pm
package Local::Config;
use Exporter qw(import);
our #EXPORT = qw( $foo $bar );
our $foo = 'Some value';
our $bar = 'Different value';
1;
To use this, merely load it with use. It will automatically import the variables that you put in #EXPORT:
# in some program
use Local::Config;
We cover lots of this sort of stuff in Intermediate Perl.
What you want to do here is a form of boilerplate management. Shoving variable declarations into a module or class file. This is a laudable goal. In fact you should shove as much boilerplate into that other module as possible. It makes it far easier to keep consistent behavior across the many scripts in a project. However shoving variables in there will not be as easy as you think.
First of all, $a and $b are special variables reserved for use in sort blocks so they never have to be declared. So using them here will not validate your test. require always searches for the file in #INC. See perlfunc require.
To declare a variable it has to be done at compile time. our, my, and state all operate at compile time and legalize a symbol in a lexical scope. Since a module is a scope, and require and do both create a scope for that file, there is no way to have our (let alone my and state) reach back to a parent scope to declare a symbol.
This leaves you with two options. Export package globals back to the calling script or munge the script with a source filter. Both of these will give you heartburn. Remember that it has to be done at compile time.
In the interest of computer science, here's how you would do it (but don't do it).
#boilerplate.pm
use strict;
use vars qw/$foo $bar/;
1;
__END__
#script.pl
use strict;
use boilerplate;
$foo = "foo here";
use vars is how you declare package globals when strict is in effect. Package globals are unscoped ("global") so it doesn't matter what scope or file they're declared in. (NB: our does not create a global like my creates a lexical. our creates a lexical alias to a global, thus exposing whatever is there.) Notice that boilerplate.pm has no package declaration. It will inherit whatever called it which is what you want.
The second way using source filters is devious. You create a module that rewrites the source code of your script on the fly. See Filter::Simple and perlfilter for more information. This only works on real scripts, not perl -e ....
#boilerplate.pm
package boilerplate;
use strict; use diagnostics;
use Filter::Simple;
my $injection = '
our ($foo, $bar);
my ($baz);
';
FILTER { s/__FILTER__/$injection/; }
__END__
#script.pl
use strict; use diagnostics;
use boilerplate;
__FILTER__
$foo = "foo here";
You can make any number of filtering tokens or scenarios for code substitution. e.g. use boilerplate qw/D2_loadout/;
These are the only ways to do it with standard Perl. There are modules that let you meddle with calling scopes through various B modules but you're on your own there. Thanks for the question!
HTH

How to get the global variable value in Perl?

Trying to understand scope resolution operator.
$a = 5;
foo();
print "Out a = $a\n";
sub foo() {
local $a = 10;
bar();
}
sub bar() {
print "Inside a = $a\n";
print "Global a = $::a\n";
}
Output from this program is :
Inside a = 10
Global a = 10
Out a = 5
I would have expected value of '$::a' to come out as '5' instead of 10. I thought that is what scope resolution operator do. Getting scoped values. In this case, no scope is given, so global value. Please correct me if there is any tweak.
What should I write to get the global value of 'a' inside bar subroutine?
You are misunderstanding ::. Perl doesn't really have global variables (leaving aside certain special identifier names); it has package variables. That is, every global variable belongs to a package. If your code has no package statement, that package is main, so $a is the same as $main::a. And having nothing before the :: is shorthand for main, so $::a is also $main::a.
If you do have a package declaration, package variables used within its scope will be contained in that package unless qualified with ::.
local gives a package variable or hash or array element a temporary value and saves the previous value to be restored when the innermost scope is left.
There is no way to access that saved value from within the scope of the local.
The opposite of global/package variables are lexical variables. You almost always will want to use lexical variables (declared with my), not package variables. Even when you do use package variables, you will hardly ever want to change their value with local. So a good case for using local is going to be truly rare.
Well, first off - don't use $a - single letter variable names are generally nasty, and that goes double for when it's used by sort.
Secondly local doesn't do what you think it does. It even says in the man page:
You really probably want to be using my instead, because local isn't what most people think of as "local". See Private Variables via my() in perlsub for details.
A local modifies the listed variables to be local to the enclosing block, file, or eval. If more than one value is listed, the list must be placed in parentheses. See Temporary Values via local() in perlsub for details, including issues with tied arrays and hashes.
So you probably want to use my, but... actually, more likely, you probably just want to not do that, and don't use globals at all.
#!/usr/bin/env perl
use strict;
use warnings;
our $number = 5;
foo();
print "Out number = $number\n";
sub foo {
my $number = 10;
print "Inside foo: $number\n";
print "Global foo $::number\n";
bar();
}
sub bar {
print "Inside bar = $number\n";
print "Global $::number\n";
}
As you can see - $number is lexically scoped to be "within foo" and doesn't persist into b.
Inside foo: 10
Global foo = 5
Inside a = 5
Global a = 5
Out number = 5
Thirdly - don't use prototypes on your subs. They don't do what you think they do.

Local and Global variables in perl

I am having few doubts about the local/our scope in Perl. I read a lot of documentation, but I am still in confusion is there. Following are the confusions
What is local scope?
what I read is -> local copies the value of global variable, change the value, user will use it and outside the block it will retain the global value
Confusion -> my does the same thing. Only benefit I see is that some variables like $package::var cannot be declared with my scope but can be declared with local scope. What else for local
What is "global" variable?
What I read is -> Its scope is within the package. Basically we put the global variable in #EXPORT array and use it or append the namespace with it to use in other packages.
I doubt -> Again if we declare variable with my scope in main only then we can access the variable throughout the package. Is that right? Is it possible to add the my scoped variables in #EXPORT array and use it in another packages?
I think global variables are declared with our keyword. Is there any other way to do so?
This question may look repetitive, but I am confused.
In terms of scoping, there are three kinds of variables in Perl.
Lexical variables are lexically scoped, which means they are only visible in the current lexical scope (basically file or block).
Package variables, on the other hand, can be used using their qualified form (e.g. $Foo::x) from anywhere in the interpreter, and they can be used without qualification by any code that shares the variable's package.
Certain package variables are visible without qualification anywhere in the interpreter. These include punctuation vars and a few named vars such as #ARGV and STDOUT. For example, $x refers to $Foo::x when in package Foo and $Bar::x when in package Bar (assuming no lexical var named $x is in scope), but $_ always refers to $::_.
Variables are destroyed when they are no longer referenced.
Lexical variables are usually destroyed when the lexical scope is exited.
Package variables are usually destroyed when the program exits.
Here are ways to create variable.
my and state create a lexical variable.
our creates a lexical variable that is aliased to the variable of the same name in the current package. In other words, our $x; is equivalent to my \$x = \$Foo::x; when in package Foo.
Package variables are created on use.
local doesn't create any variables. It simply backs up a variable until the current lexical scope is destroyed. It is restored from its backed-up value at that point.
my does the same thing.
No. local does not change the scope of a variable. While a lexical variable is only visible in a lexical scope, a localized package variable is still visible across the entire interpreter.
$x = 123;
sub foo { print "$x\n"; }
{ local $x = 456; foo(); } # 456
foo(); # 123
$x = 123;
sub foo { print "$x\n"; }
{ my $x = 456; foo(); } # 123
foo(); # 123
What else for local
local is primarily used to approximate the functionality of my for variables that cannot otherwise be declared lexically.
Historically, that was all variables. Since 5.6, only punctuation variables cannot be declared lexically.
What is "global" variable?
A global variable is a variable that can seen globally.
All package variables can be seen by any code in the interpreter, so they're all global.
Or are they? To see them from other packages, you need to qualify them. Are $x and $Foo::x the same variable?
To some, global variables refers to the set of package variables you can use unqualified. It means that package changes the set of global variables. And since the package directive is usually used on a file-basis, that means file-level lexicals are also effectively global by this definition. And they are indeed called that sometimes.
But if the package changes the set of variables that are global, then they're not really global, are they? So think some people, which only consider punctuation variables (e.g. $_) and the few named variables that can be used unqualified from anywhere (*::STDOUT) to be global.
In short, it's a pretty useless term.
Is it possible to add the my scoped variables in #EXPORT array and use it in another packages?
No. #EXPORT is used by Exporter. Exporter would not be able to find anything but package symbols (since files are compiled in fresh lexical scopes), so #EXPORT must only contain package symbols.
There are two kinds of variables, lexically scoped and globally scoped.
In Perl before version 5, there was only globally scoped. These variables are the package variables. These variables are available everywhere in the program if you use the package prefix.
The local keyword was introduced to provide a way to alter the value of one of these package global variables inside a limited scope, such as inside one subroutine. It will save the old value on a stack when entering the scope with the local statement, and upon exiting, it will restore the old value. These are still package globals, which means that they are still available everywhere. If you are inside a scope with a local variable, and you call a subroutine, that variable is still visible inside that subroutine.
The my keyword was introduced in version 5, and provides lexically scoped variables. These variables only exist inside the scope where they are declared. This means that if you call a subroutine, that my variable is not visible. Upon exiting a scope, the my variables simply go away. You should prefer to use my variables when possible, because you do not want your variables to be visible inside subroutines that you call. You cannot use these type of variables in the #EXPORT list because these variables are not visible outside of their scope.
Finally, the our keyword is a combination of both, in that it gives you a variable that is a package global, but that variable is lexically scoped. This means it will be available anywhere in the program, but at the end of the enclosing block, you cannot refer to that variable any more.
Here's what I found out about variable scopes:
my declarations are pretty clear and straightforward if used inside blocks. If used in main outside any block, they are a bit different though, meaning that a my variable declared outside a block is visible even inside functions called from anywhere inside the same file as long as these functions are defined within the same file. If declared inside a block, though, they are not visible to functions even if called from the same block. All my variables seem to live on the stack. And: you cannot localize them with local.
our variables live on the heap. Even if you have a my variable by the same name, the our variable can still be accessed through ${'var'}, which looks up a variable of that name in the symbol table and dereferences it. my variables, on the other hand, have not symbol table entries.
local variables seem to me like a relic from former Perl versions. They are just re-assignments to global (our) variables with block scope and resume their former values after the block terminates. I can see no real sense in using them.
My little program below shows all this, and it shows how badly a declared() test is missing, beyond the well-known defined() test, to identify undeclared variables as such.
#!/usr/bin/perl
use strict;
### This is about variable scoping with my, our and local
my $fsv = "file scope"; # visible for all code in this file
our $gsv = "global scope"; # not different from my $fsv, except in packages
our $lsv = "global"; # global scope, but localized in subsequent block
{
my $bsv = "lex scope"; # visible only inside this block, not even in subs called from here
$gsv = "visible everywhere";
local $lsv = "global, but localized val";
print "This is variable \$bsv with value $bsv inside block\n";
print "This is variable \$fsv with value $fsv inside block\n";
print "This is variable \$lsv with value $lsv inside block\n\n";
print_vars("calledfromblock");
}
print_vars("calledfromoutside");
no strict 'vars'; # needed if testing variable for declaredness rather than definedness
if ( defined $bsv ) {
print "\$bsv as defined outside braces: $bsv\n"
} else {
print "\$bsv not defined outside braces\n";
}
print "This is variable \$lsv with value $lsv outside block\n";
# use strict 'vars'; # no strict 'vars' effective even in sub print_vars unless switched back on
sub print_vars
{
my $whence = shift;
my $gsv = "my variable";
no strict 'refs'; # needed to access the global var $gsv using ${'gsv'} despite the my declaration
if ( $whence eq "calledfromblock" ) {
print "\t print_vars called from within the block:\n";
( defined $bsv ) ? print "\$bsv is $bsv inside sub\n" : print "\$bsv not defined inside sub\n";
( defined $fsv ) ? print "\$fsv is $fsv inside sub\n" : print "\$fsv not defined inside sub\n";
( defined ${'gsv'} ) ? print "\$gsv is ${'gsv'} inside sub\n" : print "\$gsv not defined inside sub\n";
( defined ${'lsv'} ) ? print "\$lsv is ${'lsv'} inside sub\n" : print "\$lsv not defined inside sub\n";
} else {
print "\t print_vars called from outside the block:\n";
( defined $bsv ) ? print "\$bsv is $bsv inside sub\n" : print "\$bsv not defined inside sub\n";
( defined $fsv ) ? print "\$fsv is $fsv inside sub\n" : print "\$fsv not defined inside sub\n";
( defined $gsv ) ? print "\$gsv is $gsv inside sub\n" : print "\$gsv not defined inside sub\n";
( defined $lsv ) ? print "\$lsv is $lsv inside sub\n" : print "\$lsv not defined inside sub\n";
}
print "\n";
}
###Example 1:
sub mess_with_foo {
$foo=0;
}
sub myfunc {
my $foo=20;
mess_with_foo();
print $foo;
}
myfunc();
###Example 2:
sub mess_with_foo {
$foo=0;
}
sub myfunc {
local $foo=20;
mess_with_foo();
print $foo;
}
myfunc();
Example 1 prints 20 because mess_with_foo() could not see my $foo. It could not change it. my $foo can only be seen in its scope of myfunc().
Example 2 prints 0 because mess_with_foo() can see my $foo and change it. local $foo can be seen in its scope of myfunc() AND in the scope of any function called from within its scope of myfunc().
That's the only difference. Neither my $foo nor local $foo will be seen outside of their scope of myfunc().

How does the difference between "my" and "local" interact with symbolic references?

Previously I read related content in the book of "Effective Perl Programming", but didn't really understand it. Today, I encountered a problem about this, as below code.
my $vname = "a";
my #a = qw(1 2 3);
local #array = #$vname;
foreach(#array) { print "$_\n"; };
It output nothing. Then I modified this line:
local #a = qw(1 2 3);
Just replaced "my" with "local", then it works now. So I'd like to figure out what's the difference between them.
There is a perldoc entry which answers this question in perlfaq7:
What's the difference between dynamic and lexical (static) scoping? Between local() and my()?
local($x) saves away the old value of the global variable $x and
assigns a new value for the duration of the subroutine which is
visible in other functions called from that subroutine. This is done
at run-time, so is called dynamic scoping. local() always affects
global variables, also called package variables or dynamic variables.
my($x) creates a new variable that is only visible in the current
subroutine. This is done at compile-time, so it is called lexical or
static scoping. my() always affects private variables, also called
lexical variables or (improperly) static(ly scoped) variables.
For instance:
sub visible {
print "var has value $var\n";
}
sub dynamic {
local $var = 'local'; # new temporary value for the still-global
visible(); # variable called $var
}
sub lexical {
my $var = 'private'; # new private variable, $var
visible(); # (invisible outside of sub scope)
}
$var = 'global';
visible(); # prints global
dynamic(); # prints local
lexical(); # prints global
Notice how at no point does the value "private" get printed. That's
because $var only has that value within the block of the lexical()
function, and it is hidden from the called subroutine.
In summary, local() doesn't make what you think of as private, local
variables. It gives a global variable a temporary value. my() is what
you're looking for if you want private variables.
See Private Variables via
my() in perlsub
and Temporary Values via
local() in perlsub
for excruciating details.
my creates a new variable. It can only be seen in the lexical scope in which it is declared.
local creates a temporary backup of a global variable that's restored on scope exit, but does not reduce its scope (it can still be seen globally). It does not create a new variable.
You always want to use my when possible, but local is a decent approximation when you have to deal with global variables (e.g. $_).
There are two kinds of variable scopes in Perl:
Global variables: They reside in the current package, can be accessed from the outside and can have "local" values. The name can be used as a key in the "stash", the package variable hash / the symbol table.
Lexical variables: They reside in the current scope (roughly delimited by curly braces). There is no symbol table that can be inspected.
Lexical variables and global variables do not interfere, there can be two different variables with the same name.
Most Perl variable magic happens with global variables. The following syntax works with global variables:
our $var;
$::var;
$main::var;
${'var'};
local $var;
but not my $var.
So we can write:
#::array = qw(a b c);
my #secondArray = #{array};
Which copies the arrays. We can also look up the array with a name that is stored in a variable:
#::array = qw(a b c);
my $name = "array";
my #secondArray = #{$name};
The last line abbreviates to … = #$name.
This is not possible with lexical vars because they do not reside in the stash.
The local function assigns a "local" value to a global variable (and globals only) within the current scope and in the scope of all subs that are called from within this scope ("dynamic scope").
Originally (in Perl 4) meddling with variable names and the stash was the only way to simulate references. These usages are now mostly outdated by ~2 decades as references are available (what is far safer).
I would like to focus on the main cases when you would use them :
my should be your "default" for variables that you wish to keep restricted to a specific block. This should be most of the time
local is useful if you wish to use a global variable, particular one of the special variables. For example
local $/; # enable "slurp" mode
local $_ = <$some_file_handle>; # whole file now here
Using local prevents your change from affecting other code (including modules you didnt write)
In your case, the difference is that local addressed a variable in the symbol table and my does not. This is important because of how to use it:
local #array = #$vname;
That is, you're using $vname as a symbolic reference (a questionable practice absent no strict 'refs' to tell us you know what you're doing). Quotha:
Only package variables (globals, even if localized) are visible to
symbolic references. Lexical variables (declared with my()) aren't in
a symbol table, and thus are invisible to this mechanism.
So symbolic references can only refer to variables in the symbol table. Whether you declare #a as lexical with my or as global with local, #$vname only ever refers to #main::a. When you say
local #a = qw(1 2 3);
, you are giving a new value to #main::a. When you say
my #a = qw(1 2 3);
, you are creating a new lexical variable #a and giving it a value, but leaving #main::a undefined. When
local #array = #$vname;
then accesses the value of #main::a, if finds it to be undefined and sets the value of #array to it.
If all that seems confusing, that's because it is. This is why you are strongly encouraged to use strict and warnings (which would have exploded prettily on this code) and discouraged from using symbolic references unless you really know what you're doing.

What is meant by proper closure here

This is a code lifted straight from Perl Cookbook:
#colors = qw(red blue green yellow orange purple violet);
for my $name (#colors) {
no strict 'refs';
*$name = sub { "<FONT COLOR='$name'>#_</FONT>" };
}
It's intention is to form 6 different subroutines with names of different colors. In the explanation part, the book reads:
These functions all seem independent, but the real code was in fact only compiled once. This technique
saves on both compile time and memory use. To create a proper closure, any variables in the anonymous
subroutine must be lexicals. That's the reason for the my on the loop iteration variable.
What is meant by proper closure, and what will happen if the my is omitted? Plus how come a typeglob is working with a lexical variable, even though typeglobs cannot be defined for lexical variables and should throw error?
As others have mentioned the cookbook is using the term "proper" to refer to the fact that a subroutine is created that carries with it a variable that is from a higher lexical scope and that this variable can no longer be reached by any other means. I use the over simplified mnemonic "Access to the $color variable is 'closed'" to remember this part of closures.
The statement "typeglobs cannot be defined for lexical variables" misunderstands a few key points about typeglobs. It is somewhat true it you read it as "you cannot use 'my' to create a typeglob". Consider the following:
my *red = sub { 'this is red' };
This will die with "syntax error near "my *red" because its trying to define a typeglob using the "my" keyword.
However, the code from your example is not trying to do this. It is defining a typeglob which is global unless overridden. It is using the value of a lexical variable to define the name of the typeglob.
Incidentally a typeglob can be lexically local. Consider the following:
my $color = 'red';
# create sub with the name "main::$color". Specifically "main:red"
*$color = sub { $color };
# preserve the sub we just created by storing a hard reference to it.
my $global_sub = \&$color;
{
# create a lexically local sub with the name "main::$color".
# this overrides "main::red" until this block ends
local *$color = sub { "local $color" };
# use our local version via a symbolic reference.
# perl uses the value of the variable to find a
# subroutine by name ("red") and executes it
print &$color(), "\n";
# use the global version in this scope via hard reference.
# perl executes the value of the variable which is a CODE
# reference.
print &$global_sub(), "\n";
# at the end of this block "main::red" goes back to being what
# it was before we overrode it.
}
# use the global version by symbolic reference
print &$color(), "\n";
This is legal and the output will be
local red
red
red
Under warnings this will complain "Subroutine main::red redefined"
I believe that "proper closure" just means actually a closure. If $name is not a lexical, all the subs will refer to the same variable (whose value will have been reset to whatever value it had before the for loop, if any).
*$name is using the value of $name as the reference for the funny kind of dereferencing a * sigil does. Since $name is a string, it is a symbolic reference (hence the no strict 'refs').
From perlfaq7:
What's a closure?
Closures are documented in perlref.
Closure is a computer science term with a precise but hard-to-explain
meaning. Usually, closures are implemented in Perl as anonymous
subroutines with lasting references to lexical variables outside their
own scopes. These lexicals magically refer to the variables that were
around when the subroutine was defined (deep binding).
Closures are most often used in programming languages where you can
have the return value of a function be itself a function, as you can
in Perl. Note that some languages provide anonymous functions but are
not capable of providing proper closures: the Python language, for
example. For more information on closures, check out any textbook on
functional programming. Scheme is a language that not only supports
but encourages closures.
The answer carries on to answer the question in some considerable detail.
The Perl FAQs are a great resource. But it's a bit of a waste of effort maintaining them if no-one ever reads them.
Edit (to better answer the later questions in your post):
1/ What is meant by proper closure? - see above
2/ What will happen if the my is omitted? - It won't work. Try it and see what happens.
3/ How come a typeglob is working with a lexical variable? - The variable $name is only being used to define the name of the typeglob to work with. It's not actually being used as a typeglob.
Does that help more?