I am using strict and warning in my Perl scripts to be notified if I am using undeclared variables. Thus, the interpreter will warn that $foo is undeclared in the following scriptlet:
#!/usr/bin/perl
use warnings;
use strict;
$foo = 'bar';
print ($foo);
However, if I use an undeclared variable in another namespace, I am not warned. The following scriptlet runs without warning whatsoever.
#!/usr/bin/perl
use warnings;
use strict;
$BAR::foo = 'bar';
print ($BAR::foo);
Why is this difference?
Since I have lost quite some time figuring out exactly this problem, albeit in a much larger context, I am wondering if it is possible to make Perl me warn about using undeclared variables in other namespaces, too.
When you fully specify the namespace in which a variable belongs, perl assumes you know what you are doing. See perldoc strict:
strict vars
This generates a compile-time error if you access a variable that was neither explicitly declared (using any of my, our, state, or use vars) nor fully qualified.
I don't think there is a way to detect that you have specified a non-existent variable $BAR::foo. However, if the BAR package is under your control, you can avoid using package variables in the first place by mediating access to the state of foo using accessors, and hiding the variable from other modules.
The answer to problems created by using global variables is not to use global variables.
strict vars
This generates a compile-time error if you access a variable that was neither explicitly declared (using any of my, our, state, or use vars) nor fully qualified.
Perl "trusts" users when they use fully-qualified var names. I suspect it's to allow users to sets config variables in modules that don't use use strict;.
For example, let's look at the following snippet using Data::Dumper:
local $Data::Dumper::Useqq = 1;
print(Dumper($s));
Even long after use strict; was introduced, Data::Dumper didn't declare $Useqq. There wouldn't even have been a mechanism to do so before use strict;! So the above snippet would be using an undeclared variable. That means strict code would not have been able to use Data::Dumper in the above fashion if strict vars was enforced covered fully-qualified names.
It doesn't make sense to prevent strict code from using modules that aren't strict-safe, so strict vars doesn't cover fully-qualified names. These are rare enough and easily-identifiable enough to simply have programmers take more care when using them.
I am wondering if it is possible to make Perl me warn about using undeclared variables in other namespaces, too.
I don't know of existing solutions. It might be possible to hook into Perl to do that, but it would be very hard.
Keep in mind that Perl already warns you if you only use a package variable once, so this should help you catch typos.
Hi I have a perl script named main.pl. This perl script is calling three perl modules named sub1.pm, sub2.pm, and sub3.pm. sub.pm is returning three hashes which are being used in sub2.pm and sub3.pm. I am passing the hashes as input parameter to sub2 and sub3. Instead is there any way that I can declare the hashes globally so that it will be visible to these two perl modules?
When you declare non-global variables, it is done by putting "my" in front of it. i.e.:
my $local_variable = 4;
What you are wanting to do is replace the "my" with "our" and make sure it is placed outside of a subroutine. i.e.:
our $global_variable = 4;
If you wish to use it in other modules, you can add it by the following:
use vars qw($global_variable);
Now that I told you how to do it, I am going to tell you not to do it. It is strongly discouraged to use global variables. You should use local variables whenever you can. The reason for this is because if you are ever working on a larger project or a project with multiple coders, then you might find unknown errors as certain variables might not equal what you expect them to because they were changed elsewhere.
Every variable you declare in a module XY with
our $var;
our %hash;
or
use vars qw($var %hash);
is declared global and available as
$XY::var
%XY::hash;
in every other perl-module (if the module has already been used/required).
HTH
$color_of{apple} = "red";
print $color_of{apple};
The above code is printing red when I have not even initialized the hash. Is this allowed in perl and will it always compile?
I can't remember the exact code but once I got the following error when the map wasn't initialized explicitly.
Global symbol "%map" requires explicit package name at ....
Code link : http://ideone.com/NJDTUj
You get that error when you use strict, which you should always do. You should also always use warnings to turn warnings on.
It is considered good practice and called Modern Perl (which is everything more or less after Perl 5.08, don't quote me on that) to always have strict and warnings. They make sure you don't have stupid mistakes, enforce that you declare variables, tell you about declaring them twice and so on.
So the answer is, you do not need to declare* any kind of variable in Perl, but you should do it anyway. Frankly, if you work with other people, those will hate you if you don't.
#!/usr/bin/env perl
use strict;
use warnings;
use feature 'say';
my %color_of; # no need to put () unless you explicitly want an empty list
$color_of{apple} = 'red';
say $color_of{apple};
*) Declaring a variable means you tell Perl that there is a variable. You do that with my, which makes a lexical variable that only lives inside a block (like a sub, or inside of the curly braces of if (1) { ... }. Initializing a variable means to give it a value before you use it. Usually that is done at the same time as declaring it in Perl. If you do not do that, the variable will be undef, which is perfectly fine.
An even stricter approach is to use strictures, which you need to install from CPAN.
It seems to me that many of the questions in the Perl tag could be solved if people would use:
use strict;
use warnings;
I think some people consider these to be akin to training wheels, or unnecessary complications, which is clearly not true, since even very skilled Perl programmers use them.
It seems as though most people who are proficient in Perl always use these two pragmas, whereas those who would benefit most from using them seldom do. So, I thought it would be a good idea to have a question to link to when encouraging people to use strict and warnings.
So, why should a Perl developer use strict and warnings?
For starters, use strict; (and to a lesser extent, use warnings;) helps find typos in variable names. Even experienced programmers make such errors. A common case is forgetting to rename an instance of a variable when cleaning up or refactoring code.
Using use strict; use warnings; catches many errors sooner than they would be caught otherwise, which makes it easier to find the root causes of the errors. The root cause might be the need for an error or validation check, and that can happen regardless or programmer skill.
What's good about Perl warnings is that they are rarely spurious, so there's next to no cost to using them.
Related reading: Why use my?
Apparently use strict should (must) be used when you want to force Perl to code properly which could be forcing declarations, being explicit on strings and subs, i.e., barewords or using refs with caution. Note: if there are errors, use strict will abort the execution if used.
While use warnings; will help you find typing mistakes in program like you missed a semicolon, you used 'elseif' and not 'elsif', you are using deprecated syntax or function, whatever like that. Note: use warnings will only provide warnings and continue execution, i.e., it won't abort the execution...
Anyway, it would be better if we go into details, which I am specifying below
From perl.com (my favourite):
use strict 'vars';
which means that you must always declare variables before you use them.
If you don't declare you will probably get an error message for the undeclared variable:
Global symbol "$variablename" requires explicit package name at scriptname.pl line 3
This warning means Perl is not exactly clear about what the scope of the variable is. So you need to be explicit about your variables, which means either declaring them with my, so they are restricted to the current block, or referring to them with their fully qualified name (for ex: $MAIN::variablename).
So, a compile-time error is triggered if you attempt to access a variable that hasn't met at least one of the following criteria:
Predefined by Perl itself, such as #ARGV, %ENV, and all the global punctuation variables such as $. Or $_.
Declared with our (for a global) or my (for a lexical).
Imported from another package. (The use vars pragma fakes up an import, but use our instead.)
Fully qualified using its package name and the double-colon package separator.
use strict 'subs';
Consider two programs
# prog 1
$a = test_value;
print "First program: ", $a, "\n";
sub test_value { return "test passed"; }
Output: First program's result: test_value
# prog 2
sub test_value { return "test passed"; }
$a = test_value;
print "Second program: ", $a, "\n";
Output: Second program's result: test passed
In both cases we have a test_value() sub and we want to put its result into $a. And yet, when we run the two programs, we get two different results:
In the first program, at the point we get to $a = test_value;, Perl doesn't know of any test_value() sub, and test_value is interpreted as string 'test_value'. In the second program, the definition of test_value() comes before the $a = test_value; line. Perl thinks test_value as sub call.
The technical term for isolated words like test_value that might be subs and might be strings depending on context, by the way, is bareword. Perl's handling of barewords can be confusing, and it can cause bug in program.
The bug is what we encountered in our first program, Remember that Perl won't look forward to find test_value(), so since it hasn't already seen test_value(), it assumes that you want a string. So if you use strict subs;, it will cause this program to die with an error:
Bareword "test_value" not allowed while "strict subs" in use at
./a6-strictsubs.pl line 3.
Solution to this error would be
Use parentheses to make it clear you're calling a sub. If Perl sees $a = test_value();,
Declare your sub before you first use it
use strict;
sub test_value; # Declares that there's a test_value() coming later ...
my $a = test_value; # ...so Perl will know this line is okay.
.......
sub test_value { return "test_passed"; }
And If you mean to use it as a string, quote it.
So, This stricture makes Perl treat all barewords as syntax errors. A bareword is any bare name or identifier that has no other interpretation forced by context. (Context is often forced by a nearby keyword or token, or by predeclaration of the word in question.) So If you mean to use it as a string, quote it and If you mean to use it as a function call, predeclare it or use parentheses.
Barewords are dangerous because of this unpredictable behavior. use strict; (or use strict 'subs';) makes them predictable, because barewords that might cause strange behavior in the future will make your program die before they can wreak havoc
There's one place where it's OK to use barewords even when you've turned on strict subs: when you are assigning hash keys.
$hash{sample} = 6; # Same as $hash{'sample'} = 6
%other_hash = ( pie => 'apple' );
Barewords in hash keys are always interpreted as strings, so there is no ambiguity.
use strict 'refs';
This generates a run-time error if you use symbolic references, intentionally or otherwise.
A value that is not a hard reference is then treated as a symbolic reference. That is, the reference is interpreted as a string representing the name of a global variable.
use strict 'refs';
$ref = \$foo; # Store "real" (hard) reference.
print $$ref; # Dereferencing is ok.
$ref = "foo"; # Store name of global (package) variable.
print $$ref; # WRONG, run-time error under strict refs.
use warnings;
This lexically scoped pragma permits flexible control over Perl's built-in warnings, both those emitted by the compiler as well as those from the run-time system.
From perldiag:
So the majority of warning messages from the classifications below, i.e., W, D, and S can be controlled using the warnings pragma.
(W) A warning (optional)
(D) A deprecation (enabled by default)
(S) A severe warning (enabled by default)
I have listed some of warnings messages those occurs often below by classifications. For detailed info on them and others messages, refer to perldiag.
(W) A warning (optional):
Missing argument in %s
Missing argument to -%c
(Did you mean &%s instead?)
(Did you mean "local" instead of "our"?)
(Did you mean $ or # instead of %?)
'%s' is not a code reference
length() used on %s
Misplaced _ in number
(D) A deprecation (enabled by default):
defined(#array) is deprecated
defined(%hash) is deprecated
Deprecated use of my() in false conditional
$# is no longer supported
(S) A severe warning (enabled by default)
elseif should be elsif
%s found where operator expected
(Missing operator before %s?)
(Missing semicolon on previous line?)
%s never introduced
Operator or semicolon missing before %s
Precedence problem: open %s should be open(%s)
Prototype mismatch: %s vs %s
Warning: Use of "%s" without parentheses is ambiguous
Can't open %s: %s
These two pragmas can automatically identify bugs in your code.
I always use this in my code:
use strict;
use warnings FATAL => 'all';
FATAL makes the code die on warnings, just like strict does.
For additional information, see: Get stricter with use warnings FATAL => 'all';
Also... The strictures, according to Seuss
There's a good thread on perlmonks about this question.
The basic reason obviously is that strict and warnings massively help you catch mistakes and aid debugging.
Source: Different blogs
Use will export functions and variable names to the main namespace by
calling modules import() function.
A pragma is a module which influences some aspect of the compile time
or run time behavior of Perl. Pragmas give hints to the compiler.
Use warnings - Perl complains about variables used only once and improper conversions of strings into numbers. Trying to write to
files that are not opened. It happens at compile time. It is used to
control warnings.
Use strict - declare variables scope. It is used to set some kind of
discipline in the script. If barewords are used in the code they are
interpreted. All the variables should be given scope, like my, our or
local.
The "use strict" directive tells Perl to do extra checking during the compilation of your code. Using this directive will save you time debugging your Perl code because it finds common coding bugs that you might overlook otherwise.
Strict and warnings make sure your variables are not global.
It is much neater to be able to have variables unique for individual methods rather than having to keep track of each and every variable name.
$_, or no variable for certain functions, can also be useful to write more compact code quicker.
However, if you do not use strict and warnings, $_ becomes global!
use strict;
use warnings;
Strict and warnings are the mode for the Perl program. It is allowing the user to enter the code more liberally and more than that, that Perl code will become to look formal and its coding standard will be effective.
warnings means same like -w in the Perl shebang line, so it will provide you the warnings generated by the Perl program. It will display in the terminal.
Why does this print 42:
$answer = 42;
$variable = "answer";
print ${$variable} . "\n";
but this doesn't:
my $answer = 42;
my $variable = "answer";
print ${$variable} . "\n";
Only package variables (the kind declared in your first example) can be targeted via symbolic references. Lexical (my) variables, cannot be, which is why your second example fails.
See the excellent article Coping with Scoping for how the two separate variable systems in Perl operate. And see the also excellent Why it's stupid to use a variable variable name for why that's stupid. :)
Perl has two entirely separate but largely compatible variable systems, package variables, as in your first example, and lexical variables, as in the second. There are a few things that each can do but the other cant:
Package variables are the only ones that can be:
localized (with local)
used as the target for a symbolic reference (the reason the OP's second example doesnt work)
used as barewords (sub definitions, file handles)
used with typeglobs (because that's what the symbol really is under the hood)
Lexical variables are the only ones that can be closed over (used in a lexical closure).
Using strict would help by forcing you to declare package variables with our, making the difference clearer.
There are several times where symbolic references are useful in Perl, most center around manipulating the symbol table (like writing your own import in a module rather than using Exporter, monkey-patching modules at runtime, various other meta-programming tasks). All of these are advanced topics.
For other tasks, there is usually a better way to do it such as with a hash. The general rule of thumb is to always run under use warnings; use strict; unless you know there isn't any other way but to disable a portion of the pragma (such as using no strict 'refs'; in as small a scope as possible).
Symbolic references only work with package variables. The symbol table doesn't track lexical variables (which is the entire point of them being lexical :).
The problem is that you can't use a symbolic reference to refer to a lexical variable. In both examples ${$variable} is looking for $main::answer. In the first, $answer is a package global and short for $main::answer, so the reference finds it. In the second, $answer is a lexical variable and doesn't live in any package, so the reference can't find it.
More details in perlref under heading Symbolic references.