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

Perl Typical Syntax Error Checklist


 Debugging Perl Scripts

 Recommended Links Perl Xref

Perl Style

Perl Programming Environment

 Perl POD documentation

Debugging Software Testing Program understanding Pretty Printing Perl Tips Humor Etc

Tracking down syntax errors can be troublesome, but it's a skill that comes with practice.

One of the simplest, yet most effective, techniques is to selectively remove as much of the code as possible until youíve isolated the cause of an error message. If you can get the code down to a screenful, then even if you canít find the problem, other people to whom you show the code have a chance of being able to help you.

If you want to hide code temporarily (perhaps because youíre not sure whether itís being used), then you can insert a line consisting precisely of:


(thatís two underscores on each side and no leading or trailing white space) in your program, and everything that comes after it will be ignored (actually, itís available for reading via the DATA filehandleómake sure there isnít already an __END__ or __DATA__ line in the file). You can shuttle pieces of code in and out of that section.

Usually a syntax error is easy to locate because Perl tells you the line it occurred on, or the following line. Sometimes, however, the real culprit can be many lines earlier. If youíre trying to locate the source of a really strange error that appears caused by bad syntax, you can move an __END__ line up and down the file in a binary chop and use perlís -c run-time flag to do syntax checking only (see perlrun).

To comment out a block of code in the middle of a file, use POD directives.

When youíre making modifications to how the program works, the golden rule to remember is this:

Change only one thing at a time!

You will go batty trying to figure out what caused strange new behavior if you make a whole slew of changes before trying the program out again. Once again the importance of having automated tests comes into the limelight.

Most of the errors you're likely to experience are going to fall into one of the six categories below. The list below is adapted from Simon Cozen book Beginning Perl:

Wrong format of Perl script file on one of the data files

If you write Perl script in Windows and then push it to Unix that happens often. It's better to run via dos2unix utility all files "just in case".

Missing Semicolons

This is one of the most common and most easily avoidable errors. Probably the most common syntax error there is. Every statement in Perl, unless it's at the end of a block, should finish with a semicolon. Sometimes you'll get the helpful hint we got above:

(Missing semicolon on previous line?) 

but otherwise you've just got to find it yourself. Remember that the line number you get in any error message may well not be the line number the problem occurs on ÔŅĹ just when the problem is detected.

Perl often diagnose wrong line for this error so you need to look at the line listed as a fuzzy pointer.

Missing Open/Close Brackets

The next most common error comes when you forget to open or close a bracket or brace. Missed closing braces are the most troublesome, because Perl sometimes goes right the way to the end of the file before reporting the problem. For example:

# missing_braces.plx
use warnings;
use strict;

if (1) { 
   print "Hello"; 
   my $file = shift; 
   if (-e $file) { 
      print "File exists.\n"; 

This will give us:

perl -w 
Missing right curly or square bracket at braces.plx line 12, 
at end of line syntax error at braces.plx line 12, at EOF 
Execution of braces.plx aborted due to compilation errors. > 

The problem is, our missing brace is only at line 7, but Perl can't tell that. To find where the problem is in a large file, there are a variety of things you can do:

Indent your code as we have done to make the block structure as clear as possible. This won't affect what perl sees, but it helps you to see how the program hangs together, making it more readily obvious when this sort of thing happens.

Deliberately leave out semicolons where you think a block should end, and you'll cause a syntax error more quickly. However, you'll need to remember to add the semicolon if you add extra statements to the block.

Use an editor which helps you out: most editors automatically flash up matching braces and brackets (called balancing) and are freely available for both UNIX and Windows.

Runaway String

In a similar vein, don't forget to terminate strings and regular expressions. A runaway string will cause a cascade of errors as code looks like strings and strings look like code all the way through your program. If you're lucky though, Perl will catch it quickly and tell you where it starts ÔŅĹ miss off the closing " in line 7 of the above example, and Perl will produce this message amongst the rest of the mess:

(Might be a runaway multi-line "" string starting on line 7)

This is also particularly pertinent when you're dealing with here-documents.

!/usr/bin/perl #heredoc.plx use warnings; print<<EOF; 

This is a here-document. It starts on the line after the two arrows, and it ends when the text following the arrows is found at the beginning of a line, like this:

Since perl treats everything between print<<EOF; and the terminator EOF as plain text, it only takes a broken terminator for perl to interpret the rest of your program as nothing more than a long string of characters.

Missing Comma

If you forget a comma where there should be one, you'll almost always get the 'Scalar found where operator expected' message. This is because Perl is trying to connect two parts of a statement together and can't work out how to do it.

Brackets Around Conditions

You need brackets around the conditions such as if, for, while, and their English negatives unless, until. However, you don't need brackets around the conditions when using them as statement modifiers.


If an error message contains the word 'bareword', it means that Perl couldn't work out what a word was supposed to be. Was it a scalar variable and you forgot the type prefix $? Was it a filehandle used in a wrong context?

Sometimes this error is produced because you accidentally deleted or forget to put # in the first line (she-bang operator) of the script that typically contains:


For example, if we run:

use warnings;

Perl interpreter will tell us:

Bareword found where operator expected at line 1, near "/usr/bin"
        (Missing operator before bin?)
syntax error at line 1, near "/usr/bin"
"use" not allowed in expression at line 3, at end of line had compilation errors.

Top Visited
Past week
Past month


Old News ;-)