So lets say I have a main.pl script and in that script I need to declare some variables (any kind of variable constant or normal) and those variables need to be available through all scripts and modules that I'll include from that main.pl script automatically.
What I mean if I have a variable $myVar in main.pl and from main.pl I require script1.pl, script2.pl or script3.pm, and from anyone of those scripts I need to access $myVar as you would access any var defined in that specific script or module.
I've searched on the net, but I've only found examples where you can access variables from the scripts you include or extract variables from modules; but that's not what I want.
Isn't there a keyword like in PHP where you would use global $var1, $var2 etc. to use variable from the parent script?
Any example, documentation or article is acceptable - basically anything that could help me accomplish that would be helpful.
You can declare global variables with the our keyword:
our $var = 42;
Each global variable has a fully qualified name which can be used to access it from anywhere. The full name is the package name plus the variable name. If you haven't yet declared a package at that point, you are in package main, which can be shortened to a leading ::. So the above variable has the names
$var # inside package main
$main::var # This is most obvious
$::var # This may be a good compromise
If we had used another package, the prefix would change, e.g.
package Foo;
our $bar = "baz";
# $Foo::bar from anywhere,
# or even $::Foo::bar or $main::Foo::bar
If we want to use a variable without the prefix, but under other packages, we have to export it. This is usually done by subclassing Exporter, see #Davids answer. However, this can only provide variables from packages that are being used, not the other way round. E.g.
Foo.pm:
package Foo;
use strict; use warnings;
use parent 'Exporter'; # imports and subclasses Exporter
our $var = 42;
our $not_exported = "don't look at me";
our #EXPORT = qw($var); # put stuff here you want to export
# put vars into #EXPORT_OK that will be exported on request
1;
script.pl:
#!/usr/bin/perl
# this is implicitly package main
use Foo; # imports $var
print "var = $var\n"; # access the variable without prefix
print "$Foo::not_exported\n"; # access non-exported var with full name
Lexical variables (declared with my) don't have globally unique names and can't be accessed outside their static scope. They also can't be used with Exporter.
The easiest way to do this, would be to create your own module. So, for example, if I want global access to variables $foo and $bar, then I could create a module, as follows:
# file: MyVars.pm
package MyVars;
$foo = 12;
$bar = 117.8;
1;
Then I can access these variables using any perl script that uses the MyVars module:
# file: printvars.pl
use MyVars;
print "foo = $MyVars::foo\nbar = $MyVars::bar\n";
Output:
foo = 12
bar = 117.8
Related
I have working code, but I am trying to understand why it works. I am also trying to learn more about the internals of Perl 5 (perlbrew, perl-5.26.1, Cygwin x64).
I know from perlvar and strict that use strict 'vars' works by setting flags in $^H. Perl then tests accesses to non-:: variables based on those flags. Somehow, both our and use vars mark variables so that they will pass the test. How do they do so?
For example:
perl -E 'package Foo;
use strict "vars";
use vars qw($foo);
say $foo;'
runs fine (although it produces no output). Based on the source for use vars, I tried this, which I thought would have the same effect:
perl -E 'package Foo;
use strict "vars";
my $sym = "Foo::foo"; # <-- These two lines pulled straight
*$sym = \$$sym; # <-- from the source for the vars pragma
say $foo;'
However, it gave me an error: Global symbol "$foo" requires explicit package name. I also tried $sym = "::Foo:foo" in the above, with the same result.
I checked, and $Foo::foo is in the symbol table:
$ perl -E 'package Foo;
use Data::Dumper;
use strict "vars";
my $sym = "Foo::foo";
*$sym = \$$sym;
say Dumper(\%{"Foo::"});' # <-- Foo's symbol table
Output:
$VAR1 = {
'BEGIN' => *Foo::BEGIN,
'Dumper' => *Foo::Dumper,
'foo' => *Foo::foo # <-- yep, it's there
};
What else is use vars doing that I'm missing? Does our do the same, or something different?
Update
Here's an A/B based on melpomene's answer:
Fails Succeeds
------------------------- ----------------------------------
package Foo; package Foo;
use strict "vars"; use strict "vars";
BEGIN {
package Bar;
my $sym="Foo::foo"; my $sym = "Foo::foo";
*$sym = \$$sym; *$sym = \$$sym;
}
say $foo; say $foo;
use strict 'vars' works by setting flags in $^H.
Yes, but that's an implementation detail. $^H exposes some internal interpreter state bits, but you're not supposed to touch it in normal code.
Somehow, both our and use vars mark variables so that they will pass the test. How do they do so?
This is also considered an implementation detail.
However, we can peek a bit under the hood. strict "vars" complains about undeclared variables (at compile time).
There is a hardcoded list of variables that are exempt from this check; it includes all punctuation variables (e.g. $/, $_, etc. along with $a and $b (used by sort)).
All lexically (i.e. locally) declared variables also pass strict; this is how my, our, and state work. (For our purposes local is not a declaration and does not create local variables; local temporarily changes the value of an existing variable.)
The third exception is variables exported from modules. Using global variables as part of your module interface is generally considered to be a bad idea, but some older modules still do it. English also exports variables because that's its whole point, so we'll use it as an example:
use strict;
use English qw($INPUT_RECORD_SEPARATOR);
$INPUT_RECORD_SEPARATOR = ""; # <--
my $paragraph = readline STDIN;
The line marked <-- does not throw an error because Perl remembers which variables were imported from a module.
What does "exporting" actually mean? It just means aliasing a symbol across package boundaries:
*main::foo = \$Some::Module::foo; # now $main::foo is an alias for $Some::Module::foo
The curious thing is that as far as the Perl internals are concerned, a variable is "imported" if it has been aliased in some other package. It does not matter what it was aliased to; all that matters is where the aliasing happened. use vars (ab-)uses this detail to bypass strict "vars" by exporting your own variables back at you:
package Some::Package;
use vars qw($foo);
works like
package Some::Package;
BEGIN {
package vars;
*Some::Package::foo = \$Some::Package::foo;
}
# now $foo is an alias to ... itself
The other piece of the puzzle is that use happens at compile time, like BEGIN blocks. Your example fails because your aliasing attempt only happens at runtime, which is too late for strict, and because it doesn't switch to a different package to do the aliasing.
In the end vars is just a module, written in plain Perl. our is different: It is a real keyword and part of the language. It also has different behavior: It effectively creates an alias (to a package variable), but that alias lives in a local scope, not the symbol table.
Consider e.g. the following:
my $foo = 2;
{
our $foo = "hello";
print "foo = $foo; main::foo = $main::foo\n";
}
print "foo = $foo; main::foo = $main::foo\n";
This outputs
foo = hello; main::foo = hello
foo = 2; main::foo = hello
because the inner our $foo declaration shadows the outer $foo in the inner block. Within the block both $foo and $main::foo refer to the same variable; outside $foo refers to the lexical my $foo, which is untouched.
Another difference to use vars:
use strict;
package Foo;
our $x = "hello";
package Bar;
print "$x\n"; # hello
This code works fine because package declarations don't create a new scope. There is only one unit of scoping here (the whole file), and so our $x makes $x refer to $Foo::x for the rest of the file, no matter which package you switch into.
On the other hand:
use strict;
package Foo;
use vars qw($x);
$x = "hello";
package Bar;
print "$x\n";
This code doesn't even compile. The reference to $x in the last line can't be resolved: Perl checks the local scope first, but there are no locally declared $x's. It then checks the current package (Bar) and finds nothing either, and without strict "vars" it would have automatically created $Bar::x for you, but with strict "vars" enabled this is simply an error. $Foo::x is irrelevant and never checked.
I am stuck while creating a perl Moose module.
I have a global pm module.
package XYZ;
require Exporter;
our #ISA = qw(Exporter); ## EDIT missed this line
our #EXPORT_OK = qw($VAR);
my $VAR1 = 1;
our $VAR = {'XYZ' => $VAR1};
1;
I want to get $VAR in a Moose module I'm creating
package THIS;
use Moose;
use YAML::XS;
sub get_all_blocks{
my ($self) = #_;
require $self->get_pkg(); # this returns the full path+name of the above package
# i cannot use use lib+use since the get_pkg starts complaining
our $VAR;
print YAML::XS::Dump($XYZ::VAR); # this works
print YAML::XS::Dump($VAR); # this does not work
# i cannot use the scope resolution since XYZ would keep changing.
}
1;
Can someone please help me with accessing variable?
EDIT: Missed one line in the package XYZ code.
I cannot touch the package XYZ since it is owned/used by someone else, I can just use it :(
Exporting variables may easily lead to trouble.
Why not
package XYZ;
use strict;
use warnings;
use Exporter qw(import);
our #EXPORT_OK = qw(get_var);
my $VAR = '...'; # no need for "our" now
sub get_var { return $VAR }
...
1;
and then
package THIS;
use warnings;
use strict;
use XYZ qw(get_var);
my $var = get_var();
...
1;
See Exporter.
As for what you tried to do, there are two direct problems
$VAR from XYZ is never imported into THIS. If you need symbols from other packages you need to import them.† Those packages have to make them available first, so you need to add it to #EXPORT_OK as well.
Like above but with $VAR instead of get_var()
package XYZ;
...
use Exporter qw(import);
our #EXPORT_OK = qw($VAR);
our $VAR = '...'; # need be "our" for this
with
package THIS;
...
use XYZ qw($VAR);
print "$VAR\n";
Now $VAR can be used directly, including being written to (unless declared constant); that can change its value under the feet of yet other code, which may never even know about any of it.
Another way is to use #EXPORT and then those symbols are introduced into every program that says use Package;. I strongly recommend to only use #EXPORT_OK, when callers need to explicitly list what they want. That also nicely documents what is being used.
Even once you add that, there is still a variable with the same name in THIS, which hides (masks, shadows) the $XYZ::VAR. So remove our $VAR in THIS. This is an excellent example of one problem with globals. Once they're introduced we have to be careful about them always and everywhere.
But there are far greater problems with sharing variables across modules.
It makes code components entangled and the code gets harder and harder to work with. It runs contrary to principles of well defined scopes and modular design, it enables action at a distance, etc. Perl provides many good tools for structuring code and we rarely need globals and shared variables. It is telling that the Exporter itself warns against that.
Note how now my $VAR in XYZ is not visible outside XYZ; there is no way for any code outside XYZ to know about it or to access it.‡ When it is our then any code in the interpreter can write it simply as $XYZ::VAR, and without even importing it; that's what we don't want.
Of course that there may be a need for or good use of exporting variables, what can occasionally be found in modules. That is an exception though, to be used sparingly and carefully.
† Unless they're declared as package globals under a lexical alias via our in their package, in which case they can be used anywhere as $TheirPackageName::varname.
‡ This complete privacy is courtesy of my.
You do not want our $VAR; in THIS's namespace. That creates a lexical reference to $THIS::VAR. Not what you want.
Instead, you need to use properly:
use XYZ qw($VAR);
However, XYZ doesn't have an import to run here, so you need to update that. There are two ways to fix XYZ to do this - one is to import import, e.g., use Exporter qw(import);, the other is to derive off Exporter, e.g., use parent qw(Exporter);. Both of these will get XYZ->import(...) to work properly.
Once XYZ is useing Exporter correctly, then the use XYZ qw($VAR); line will cause perl to implicitly load XYZ and call XYZ->import(qw($VAR)), which will import that variable into your namespace.
Now, having answered your question, I will join others in suggesting that exporting variables is a very bad code smell, and probably is not the best / cleanest way to do what you want.
I am able to use the variables from imported .pm file. I can use the variables from .pl file. But when I add 'use strict' to the code it didnt work.
I tried the following
source.pl
{
var = 22;
}
1;
main.pl
use strict;
my $ref = do "source.pl";
my ($mainvar) = #$ref{ qw(var) };
print "$mainvar\n";
here its printing the $mainvar as empty string. Please help
There are two basic Perl variable types:
my - These are lexically scoped. This means that they fall in and out of existence depending upon where they're defined. Lexically scoped variables are only defined in the block they're in. If they're defined in a file, they're only accessible to that file.
our - These are package variables. A package is just Perl creating a namespace that's specific to that area of the code (usually an entire file).
In Perl, when you're in a package, you can use the variables without any prefix. Otherwise, you need to prefix variable (and subroutine names) with their package name. Think of File::Find's$File::Find::dir. That's the$dirvariable in theFile::Find` package.
When you use strict;, you must either declare your variable with either our (for package variables or my (for lexically scoped variables, or use the full package name of that variable:
source.pl
use strict;
use warnings;
our $var = 22;
test.pl
use strict;
use warnings;
do "source.pl";
our $var; #Merely a declaration -- Doesn't change the value
my $local_var = $var;
print "$local_var\n";
You could have done this too:
use strict;
use warnings;
no warnings qw(once);
do "source.pl";
my $local_var = $main::var; #Specified full package name of variable
print "$local_var\n";
I had to use no warnings qw(once); to remove the warning that $main::var is only used once.
I have a question relating to Perl and scoping. I have a common file with lots of various variables. I require the common file in my main script, but I cannot access the variables; they seem to be outside of its scope. I assumed that an our declaration would overcome that problem, but it doesn't seem to work.
Script 1: common.pl
#!/usr/bin/perl
our $var1 = "something";
our $var2 = "somethingelse";
Script 2: ftp.pl
#!/usr/bin/perl
use strict;
use warnings;
require('common.pl');
print $var1;
I get the error: Global symbol "$var1" requires explicit package name
There's no require statement in your second example, but it wouldn't work anyway. What our does is declare a lexically-scoped package variable. Since you have no package statement, it uses the default package main. So your first script sets up the variable $main::var1, but this will only be available within that file's scope.
A better way to provide common variables for other scripts is to use Exporter. You can define package symbols in one place and Exporter will take care of copying them to the requesting script or class's namespace when needed.
I would put the config in a module instead.
File: MyConfig.pm
package MyConfig;
require Exporter;
use strict;
our #ISA = qw(Exporter);
our #EXPORT = qw( getconfig );
my %confighash = (
thisone => 'one',
thatone => 2,
somthingelse => 'froboz',
);
sub getconfig {
return %confighash;
}
1;
Example usage:
#!/usr/bin/perl
use strict;
use warnings;
use MyConfig;
my %config = getconfig();
print $config{ somthingelse };
This should print froboz
It looks like you need a proper configuration file there. I'd go for a non-code configuration file that you can read when you need to setup things. There are modules on CPAN to handle just about any configuration format you can imagine.
If you want to do it the way you have it, get rid of our and declare them with use vars. Don't let the PBP police scare you off that. :) You only really need our to limit a scope of a package variable, and that's exactly the opposite of what you are trying to do.
our() does something a little different than you think. Its sole purpose is to work with strict in requiring you to declare package variables that you are going to use (unless they are fully-qualified or imported). Like strict, its effect is lexically-scoped. To use it to allow accessing a global $main:var1 from multiple files (which are separate scopes) as just $var1, you need to say our $var1 in each file.
Alternatively, you would change your required file to be a module with its own package that exports the variables to any package that uses it.
Try this. I am new at Perl but this is how I got it to work on a script I made
#!/usr/bin/perl
$var1 = "something";
$var2 = "somethingelse";
Script 2: ftp.pl
#!/usr/bin/perl
use strict;
use warnings;
our $var1;
our $var2;
require('common.pl');
print $var1;
I know what my is in Perl. It defines a variable that exists only in the scope of the block in which it is defined. What does our do?
How does our differ from my?
How does our differ from my and what does our do?
In Summary:
Available since Perl 5, my is a way to declare non-package variables, that are:
private
new
non-global
separate from any package, so that the variable cannot be accessed in the form of $package_name::variable.
On the other hand, our variables are package variables, and thus automatically:
global variables
definitely not private
not necessarily new
can be accessed outside the package (or lexical scope) with the
qualified namespace, as $package_name::variable.
Declaring a variable with our allows you to predeclare variables in order to use them under use strict without getting typo warnings or compile-time errors. Since Perl 5.6, it has replaced the obsolete use vars, which was only file-scoped, and not lexically scoped as is our.
For example, the formal, qualified name for variable $x inside package main is $main::x. Declaring our $x allows you to use the bare $x variable without penalty (i.e., without a resulting error), in the scope of the declaration, when the script uses use strict or use strict "vars". The scope might be one, or two, or more packages, or one small block.
The PerlMonks and PerlDoc links from cartman and Olafur are a great reference - below is my crack at a summary:
my variables are lexically scoped within a single block defined by {} or within the same file if not in {}s. They are not accessible from packages/subroutines defined outside of the same lexical scope / block.
our variables are scoped within a package/file and accessible from any code that use or require that package/file - name conflicts are resolved between packages by prepending the appropriate namespace.
Just to round it out, local variables are "dynamically" scoped, differing from my variables in that they are also accessible from subroutines called within the same block.
An example:
use strict;
for (1 .. 2){
# Both variables are lexically scoped to the block.
our ($o); # Belongs to 'main' package.
my ($m); # Does not belong to a package.
# The variables differ with respect to newness.
$o ++;
$m ++;
print __PACKAGE__, " >> o=$o m=$m\n"; # $m is always 1.
# The package has changed, but we still have direct,
# unqualified access to both variables, because the
# lexical scope has not changed.
package Fubb;
print __PACKAGE__, " >> o=$o m=$m\n";
}
# The our() and my() variables differ with respect to privacy.
# We can still access the variable declared with our(), provided
# that we fully qualify its name, but the variable declared
# with my() is unavailable.
print __PACKAGE__, " >> main::o=$main::o\n"; # 2
print __PACKAGE__, " >> main::m=$main::m\n"; # Undefined.
# Attempts to access the variables directly won't compile.
# print __PACKAGE__, " >> o=$o\n";
# print __PACKAGE__, " >> m=$m\n";
# Variables declared with use vars() are like those declared
# with our(): belong to a package; not private; and not new.
# However, their scoping is package-based rather than lexical.
for (1 .. 9){
use vars qw($uv);
$uv ++;
}
# Even though we are outside the lexical scope where the
# use vars() variable was declared, we have direct access
# because the package has not changed.
print __PACKAGE__, " >> uv=$uv\n";
# And we can access it from another package.
package Bubb;
print __PACKAGE__, " >> main::uv=$main::uv\n";
Coping with Scoping is a good overview of Perl scoping rules. It's old enough that our is not discussed in the body of the text. It is addressed in the Notes section at the end.
The article talks about package variables and dynamic scope and how that differs from lexical variables and lexical scope.
The perldoc has a good definition of our.
Unlike my, which both allocates storage for a variable and associates a simple name with that storage for use within the current scope, our associates a simple name with a package variable in the current package, for use within the current scope. In other words, our has the same scoping rules as my, but does not necessarily create a variable.
my is used for local variables, whereas our is used for global variables.
More reading over at Variable Scoping in Perl: the basics.
I ever met some pitfalls about lexical declarations in Perl that messed me up, which are also related to this question, so I just add my summary here:
1. Definition or declaration?
local $var = 42;
print "var: $var\n";
The output is var: 42. However we couldn't tell if local $var = 42; is a definition or declaration. But how about this:
use strict;
use warnings;
local $var = 42;
print "var: $var\n";
The second program will throw an error:
Global symbol "$var" requires explicit package name.
$var is not defined, which means local $var; is just a declaration! Before using local to declare a variable, make sure that it is defined as a global variable previously.
But why this won't fail?
use strict;
use warnings;
local $a = 42;
print "var: $a\n";
The output is: var: 42.
That's because $a, as well as $b, is a global variable pre-defined in Perl. Remember the sort function?
2. Lexical or global?
I was a C programmer before starting using Perl, so the concept of lexical and global variables seems straightforward to me: it just corresponds to auto and external variables in C. But there're small differences:
In C, an external variable is a variable defined outside any function block. On the other hand, an automatic variable is a variable defined inside a function block. Like this:
int global;
int main(void) {
int local;
}
While in Perl, things are subtle:
sub main {
$var = 42;
}
&main;
print "var: $var\n";
The output is var: 42. $var is a global variable even if it's defined in a function block! Actually in Perl, any variable is declared as global by default.
The lesson is to always add use strict; use warnings; at the beginning of a Perl program, which will force the programmer to declare the lexical variable explicitly, so that we don't get messed up by some mistakes taken for granted.
This is only somewhat related to the question, but I've just discovered a (to me) obscure bit of perl syntax that you can use with "our" (package) variables that you can't use with "my" (local) variables.
#!/usr/bin/perl
our $foo = "BAR";
print $foo . "\n";
${"foo"} = "BAZ";
print $foo . "\n";
Output:
BAR
BAZ
This won't work if you change 'our' to 'my'.
print "package is: " . __PACKAGE__ . "\n";
our $test = 1;
print "trying to print global var from main package: $test\n";
package Changed;
{
my $test = 10;
my $test1 = 11;
print "trying to print local vars from a closed block: $test, $test1\n";
}
&Check_global;
sub Check_global {
print "trying to print global var from a function: $test\n";
}
print "package is: " . __PACKAGE__ . "\n";
print "trying to print global var outside the func and from \"Changed\" package: $test\n";
print "trying to print local var outside the block $test1\n";
Will Output this:
package is: main
trying to print global var from main package: 1
trying to print local vars from a closed block: 10, 11
trying to print global var from a function: 1
package is: Changed
trying to print global var outside the func and from "Changed" package: 1
trying to print local var outside the block
In case using "use strict" will get this failure while attempting to run the script:
Global symbol "$test1" requires explicit package name at ./check_global.pl line 24.
Execution of ./check_global.pl aborted due to compilation errors.
Just try to use the following program :
#!/usr/local/bin/perl
use feature ':5.10';
#use warnings;
package a;
{
my $b = 100;
our $a = 10;
print "$a \n";
print "$b \n";
}
package b;
#my $b = 200;
#our $a = 20 ;
print "in package b value of my b $a::b \n";
print "in package b value of our a $a::a \n";
Let us think what an interpreter actually is: it's a piece of code that stores values in memory and lets the instructions in a program that it interprets access those values by their names, which are specified inside these instructions. So, the big job of an interpreter is to shape the rules of how we should use the names in those instructions to access the values that the interpreter stores.
On encountering "my", the interpreter creates a lexical variable: a named value that the interpreter can access only while it executes a block, and only from within that syntactic block. On encountering "our", the interpreter makes a lexical alias of a package variable: it binds a name, which the interpreter is supposed from then on to process as a lexical variable's name, until the block is finished, to the value of the package variable with the same name.
The effect is that you can then pretend that you're using a lexical variable and bypass the rules of 'use strict' on full qualification of package variables. Since the interpreter automatically creates package variables when they are first used, the side effect of using "our" may also be that the interpreter creates a package variable as well. In this case, two things are created: a package variable, which the interpreter can access from everywhere, provided it's properly designated as requested by 'use strict' (prepended with the name of its package and two colons), and its lexical alias.
Sources:
http://perldoc.perl.org/functions/our.html
http://perldoc.perl.org/perlsub.html#Private-Variables-via-my()
#!/usr/bin/perl -l
use strict;
# if string below commented out, prints 'lol' , if the string enabled, prints 'eeeeeeeee'
#my $lol = 'eeeeeeeeeee' ;
# no errors or warnings at any case, despite of 'strict'
our $lol = eval {$lol} || 'lol' ;
print $lol;