Introduction to Perl 5.10 for Unix System Administrators

(Perl 5.10 without excessive complexity)

by Dr Nikolai Bezroukov

Contents : Foreword : Ch01 : Ch02 : Ch03 : Ch04 : Ch05 : Ch06 : Ch07 : Ch08 :

Prev | Up | Contents | Down | Next

2.5. Typical Errors and pitfalls

It is important to use strict in your scripts. If you hate to declare variables you still can use it in the weaker form:

 use strict 'subs';

instead of "full" strict mode; it is better then nothing and will point out to a lot of errors that otherwise might remain hidden. But declaring variables is actually a good practice for longer scripts (say over 256 lines without comments).

Most typical for beginners Perl errors that probably should be checked before submitting script to the interpreter.

They include:

1. Absence of semicolon at the end of statement. This is a problem for both novices and experienced Perl programmers alike;  something in human nature prevent putting semicolons  at the end of line. and that means that language that use new line as "weak" semicolon are preferable (if brackets are balanced at this point).

2. Absence of prefix $ from the scalar variable like in if (i==1) {...}

3. Missing quote in single or a double quote literals like

   if( $a eq abba' ){ 
     print "this is my favorite group\n";
   }

4. Usage of "==" instead of "eq" and similar mistakes with other operators ( != instead  of  ne or vise versa, <  instead of lt,  > instead of gt, etc.) for example:

   if( $a == 'abba' ){ 
     print "this is my favorite group\n";
   }

5. Usage of prefix @ instead of $ for scalar variables. It is especially typical for references of elements of the array, for example @array[1] is incorrect, should be $array[1].

6. Missing closing ")" or "}". Without pretty printer missing "}" in longer  scripts is very difficult to find.

7. Wrong brackets in hash (should be { and }).

A very typical mistake connected with double-quoted literals is putting in it a email address (or group of e-mail addresses). The same applied to backquotes, for example

`cat letter | mailx -s test  [email protected]`

Here @mydomain will interpreted as an array with very undesirable results.  The correct form should be

`cat letter | mailx -s test  myself\@mydomain.my

or

$to_addr='myself\@mydomain.my";
`cat letter | mailx -s test  $to_addr`;

More extensive collection of typical errors classified by the language from which the programmer is coming to Perl (awk, C, etc) can be found in man page perltrap

NEWS CONTENTS

Old News ;-)

Variable declaration in Perl

One of the 3 features of use strict which is also called use strict 'vars'; requires that you declare every variable before you use it. Well, sort of.

Are you serious about Perl? Check out my Beginner Perl Maven book.
I have written it for you!

The trouble

Let's see first an example why is this important.

1. $l1 = 42;
3. $ll++;
5. print "$l1\n";

We assign 42 to a variable. Later we increment it by one, and then print it. Surprisingly the variable still contains 42.

The author might even know that he has to declare the variables using my so maybe the code looks like this:

1. my $l1 = 42;
3. $ll++;
5. print "$l1\n";

but the result is the same.

Now imagine that it is not in a 3 lines long example, but in a 1000 lines long script that you can find in many established places. You'd have a very hard time noticing that the auto-increment used the letter l twice, while the first and third rows had a variable with a letter and a number 1.

use strict

If we add a use strict requirement at the beginning of the file,

1. use strict;
3. my $l1 = 42;
5. $ll++;
7. print "$l1\n";

we will get the following compile-time error message when we try to run the script:

Global symbol "$ll" requires explicit package name at ... line 6.

Seeing that error message isn't that clear either, at least not for the beginners, we'll see later where does it come from. In the meantime, if you are interested, you can read more about the error global symbol requires explicit package name.

In practical terms it means that you have not declared your variable $ll. Of course running to your editor and declaring my $ll won't do any good. You'll have to understand that this is actually a typo and the real variable name is $l1.

We might be still frustrated by the original developer who used a variable name that's hard to differentiate from a letter, but at least we don't spend hours banging our head against the wall.

The exceptions

As in any living languages (such as English and French) there are exceptions from the rules. In Perl too.

The variables $a and $b are special variables used in the sort function of Perl and, for historical reasons, are exempt from the requirement to declare them. I am not saying having such exceptions is a good thing, but it probably cannot be changed without breaking all the code written in the past 20+ years. So I'd strongly recommend never using $a and $b in any code except in connection to sort.

Not even in examples!

You can declare variables using our, use vars, and since 5.10 using state as well. They have different meaning though.

You can also access variables with their fully qualified name ($Person::name in the next example):

examples/fully_qualified_name.pl

1. use 5.010;
2. use strict;
4. state $x = 42;
5. say $x;
7. our $y = 37;
8. say $y;
10. use vars qw($z);
11. $z = 100;
12. say $z;
14. $Person::name = 'Foo';
15. say $Person::name;

And the output is

42
37
100
Foo

No warning, no error.

We used the explicit package name in the last example. That's, by-the-way where the error message (global symbol requires explicit package name) came from, but in the real world you rarely need that form. You are way better off always declaring your variables using my, and not using this "fully qualified" form of the variable.

The danger of the explicit package name

As use strict does not apply to the package variables, you can easily make a typo as I actually did when I wrote the first version of the example:

examples/fully_qualified_name_with_typo.pl

1. use 5.010;
2. use strict;
4. $Person::name = 'Foo';
5. say $Perlson::name;

and it printed nothing. No error. No warning. Nothing.

In general relying on fully qualified names can be dangerous. Of course they can be useful in some places, but we'll talk about that another time.

use warnings

Anyway, this brings me to the importance of the use warnings pragmata. If we used that too,

examples/fully_qualified_name_with_warnings.pl

1. use 5.010;
2. use strict;
3. use warnings;
5. $Person::name = 'Foo';
6. say $Perlson::name;

we would get the following run-time warnings:

Name "Person::name" used only once: possible typo at ...  line 6.
Name "Perlson::name" used only once: possible typo at ... line 7.
Use of uninitialized value $Perlson::name in say at ... line 7.

Might not be the best solution, but at least we get some indication that something went wrong.

Even that warning can disappear if I am extremely bad at typing.

examples/fully_qualified_name_bad_typing.pl

1. use 5.010;
2. use strict;
3. use warnings;
5. $Perlson::name = 'Moo';
7. $Person::name = 'Foo';
8. $Person::name = 'Bar';
10. say $Perlson::name;

Here I made the exact same typo twice (maybe a copy paste?) and the result is

Moo

No error. No warning. Still incorrect behavior.

Always use strict

My conclusion is to always use strict by default.

In other articles you can read about symbolic references and barewords in Perl, the other two issues strict helps to avoid.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Variable declaration in Perl

Etc

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. 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.

Last modified: October 01, 2019