What Perl Is, and What It Was Built For

Part I · Module 1 · Chapter 1.1 · What Perl Is, and What It Was Built For

1. Two Things Called Perl

When someone says "we still use Perl here", they could mean either of two things, and both are correct.

Perl the language is a set of rules for writing instructions: which words mean what, where the punctuation goes, and what counts as a mistake. A language does nothing on its own, in the same way that English grammar does not deliver a letter.

Perl the program is a piece of software installed on the machine in front of you. You hand it a file of instructions written in the language, and it carries them out. This program is called the interpreter, and on a Unix-like system it is usually a file called perl.

A file of instructions is called a script. There is nothing special about such a file — it is ordinary text, conventionally named with a .pl ending, which you can open and read in any editor. The .pl is a convention for your benefit and your colleagues', not a rule the system enforces.

What are Perl scripts normally used for? Overwhelmingly, three things: reading text, changing text, and moving information between programs that were never designed to talk to each other. Perl is unusually direct at those jobs because searching for a pattern in text is part of the language itself, rather than something you reach for a library to do. Module 11 is where that pays off.

2. Why Perl Was Created

Perl was written by Larry Wall in 1987, and the problems it was built for are worth knowing, because they explain nearly every design decision you will meet later.

In the late 1980s a Unix engineer handling text had a collection of separate small tools — one to filter lines, one to substitute text, one to cut out columns, and a shell to glue them together. Each was good at its one job. The difficulty was everything else: the moment a task needed to search for a pattern and do arithmetic and keep a running total and write a report, you were gluing several tools together through pipes and quoting rules, and the result was hard to read and harder to change.

Perl was built to be one language that could do that whole job. Concretely, it was aimed at:

• Repetitive text processing — the same tidy-up applied to a thousand files.
• Reading and transforming files — take a file in one shape, write it out in another.
• Searching for patterns — finding the lines that matter among the lines that do not.
• Automating command-line work — turning a sequence you keep typing into one command.
• Connecting different tools — running another program and making sense of what it printed.

That list is still an accurate description of what Perl is used for today, and it is exactly why it took hold in semiconductor engineering, where a working day produces an enormous volume of text that some other program has to read. §6 shows the shape of that, and Part II is entirely about it.

3. How a Perl Script Runs

Here is the model, and it is worth getting right the first time because a common description of it is wrong.

1. You write instructions into an ordinary text file.
2. You ask the Perl interpreter to run that file.
3. Perl reads the whole file and checks that it can understand all of it. This stage is called compiling.
4. Only if that succeeds does Perl carry out the instructions, in order, from the top.
5. Anything you asked it to display appears in your terminal. If something goes wrong, a message appears instead.

You will often read that Perl "runs your file line by line". That is a convenient shorthand and it is not true. The difference is not academic: it is the reason a mistake near the end of a file can stop the beginning of the file from producing any output at all. You will see that happen for real in §7, and once you have, the error messages in the rest of the course stop being surprising.

There is no separate build step for you to manage and no executable file to produce first — you edit the text and run it again.

4. Your First Perl Program

Put these four lines in a file called hello.pl:

use strict;
use warnings;

print "Hello, Perl!\n";

Run it by handing the file to the interpreter:

perl hello.pl

Hello, Perl!

Every part of that program is worth naming:

• print displays something. It writes the text you give it to your terminal.
• The text in double quotes is the thing to display. The quotes mark where the text starts and ends — they are part of the instruction, not part of the message, which is why they do not appear in the output.
• \n means "start a new line here". It is two characters in your file, a backslash and an n, and Perl turns them into a single newline character. Without it, the next thing printed would continue on the same line — §7 shows what that looks like.
• The semicolon ends the statement. In Perl it is a full stop: it tells the interpreter that this instruction is complete and another may follow. It is required, not decorative.
• use strict; and use warnings; are two settings that make Perl stricter about what it accepts. use strict makes Perl reject some common mistakes outright, and use warnings makes it tell you when something looks suspicious rather than quietly carrying on. They do nothing visible in a program this small. Put them at the top of every script anyway — Chapters 1.10 and 1.11 cover exactly what each one catches.

You do not need to understand anything else to run this. If Hello, Perl! appeared in your terminal, the language, the interpreter and your editor are all working, and everything that follows in Part I builds on that.

5. A Program That Does Something Useful

The next program prints a small set of results. It introduces one new thing about print: it can take several items separated by commas, and an item that is not in quotes is worked out before it is printed.

use strict;
use warnings;

print "Student: Ravi\n";
print "Maths:   72\n";
print "Physics: 65\n";
print "Total:   ", 72 + 65, "\n";

Student: Ravi
Maths:   72
Physics: 65
Total:   137

The first three lines are the same instruction you already know, used three times. The fourth is the new part, and it has three items separated by commas:

1. "Total: " — text, printed as written.
2. 72 + 65 — not text, because it is not in quotes. Perl works out the sum first and prints the answer, which is why the output shows 137 rather than 72 + 65.
3. "\n" — the newline, so anything printed afterwards starts on a fresh line.

That difference between "72 + 65" and 72 + 65 is the first genuinely important thing about Perl in this lesson. Anything inside quotes is text and is printed exactly as it appears. Anything outside quotes is treated as something to work out. Chapter 2.5 returns to this properly.

Notice also that the extra spaces inside the quotes are what line the values up in the output. Perl does not align anything for you; the alignment is text you typed. Chapter 4.8 shows the tool for doing that properly when the values are not known in advance.

6. Where Perl Shows Up in Chip Design

This section needs four terms, so here they are in one line each.

A chip design is checked before it is built by running it in software. That run is a simulation: a program exercises the design and reports what happened. The report it writes is a log — a plain text file, often a very large one. A regression is the overnight job that runs hundreds of such simulations so a team arrives to a summary of which ones passed.

Perl's place in that picture is the text. A simulation log is text; a timing report is text; a list of design files is text. Something has to read those files and turn them into a short answer a person or another program can act on, and for many years that something was very often a Perl script.

Here is the shape of what such a script produces. It is a summary of one simulation run, and at this stage it is only print statements — the same instruction from §4:

use strict;
use warnings;

print "test:    alu_smoke\n";
print "errors:  0\n";
print "result:  PASS\n";

test:    alu_smoke
errors:  0
result:  PASS

alu_smoke is just a name someone gave a test. PASS means the simulation finished and reported no errors; FAIL means it did not.

Be clear about what this program does and does not do. It prints a fixed summary that someone typed. A real version has to open the log file, search it for lines reporting an error, count them, decide between PASS and FAIL based on that count, and tell the calling program the verdict. Each of those is a specific skill with its own chapter: reading a file in Module 13, searching text in Module 11, making a decision in Module 8, and reporting a verdict to another program in Module 15. Part II then puts them together on real logs.

7. Mistakes Everyone Makes First

These five account for most first-hour problems. Every message below is the real output from perl 5.34.1 — the exact wording can vary slightly between major Perl versions, so match the shape of the message rather than the characters.

1. A missing semicolon. The statement on line 4 is not finished, so Perl reads line 5 as a continuation of it and finds something that cannot follow.

use strict;
use warnings;

print "Hello, Perl!\n"
print "Second line\n";

syntax error at nosemi.pl line 5, near "print"
Execution of nosemi.pl aborted due to compilation errors.

Two things are worth noticing. The error names line 5, but the mistake is on line 4 — Perl reports the point where it realised something was wrong, not where it went wrong, so always look at the line above as well. And Hello, Perl! was never printed, even though its line comes first. That is the compile-then-run model from §3 doing exactly what it says: the file failed its check, so nothing ran.

2. Forgetting a quotation mark. With the closing quote missing, Perl keeps looking for where the text ends and runs out of file. Saved as noquote.pl, that gives:

Can't find string terminator '"' anywhere before EOF at noquote.pl line 4.

EOF means end of file. The fix is to count the quotes on the line the message names; they should come in pairs.

3. Confusing the script with the interpreter. The file is instructions for perl; it is not a program by itself. Try to run it directly and the first thing you meet is usually a refusal, because a newly created file is not marked as executable:

bash: ./hello.pl: Permission denied

Mark it executable with chmod +x hello.pl and the shell will attempt the job instead — and the shell does not know any Perl:

./hello.pl: line 1: use: command not found
./hello.pl: line 2: use: command not found
./hello.pl: line 4: print: command not found

Both messages come from your shell, not from Perl: use and print are Perl instructions, and the shell has no such commands. The fix for now is to run perl hello.pl. Chapter 1.4 shows the one line you add to a file so the shell knows to hand it to perl itself.

A related slip is a typo in the file name, which produces a clearer message:

Can't open perl script "helo.pl": No such file or directory

4. Expecting print to add a new line. It does not. Nothing is wrong with this program, but its output is probably not what you intended:

use strict;
use warnings;

print "Maths: 72";
print "Physics: 65";

Maths: 72Physics: 65

The two results are run together because neither print ended with \n. Add one to each.

5. Reading a message that does not sound related. This is the one that costs the most time. Forgetting the quotes entirely gives:

use strict;
use warnings;

print Hello, Perl!;

No comma allowed after filehandle at bareword.pl line 4.

Nothing in that sentence mentions quotation marks, and you have not met a filehandle yet. What happened is that Perl saw an unquoted word where print can legitimately be told where to print, took Hello as that destination, and then objected to the comma. The lesson is general and worth adopting now: a confusing Perl message is usually the consequence of your mistake rather than a description of it. Use the line number, check the simplest explanation first — here, missing quotes — and do not assume the message is talking about the thing you were thinking about.

8. What You Should Be Able to Say Now

Check yourself against these five. If any is unclear, this is the chapter to re-read, because everything after it assumes all five.

1. Perl is both a language and a program; the program that runs your code is the interpreter.
2. A Perl script is an ordinary text file, conventionally ending in .pl.
3. Perl checks the whole file before it runs any of your program's instructions, then carries them out in order.
4. print displays text; the quotes delimit the text; \n makes a new line; the semicolon ends a statement.
5. An error message names where Perl noticed a problem, which is not always where the problem is.

9. Exercise

Everything needed is in §4 and §5. No variables, conditions, loops or files are required.

Exercise 1 — write and run it. Create a file called practice.pl that prints exactly these two lines, where the second number is produced by Perl adding 40 and 35 rather than by you typing 75:

Name: Asha
Marks: 75

You need the two settings from §4 at the top and two print statements — the second of them comma-separated, as in §5. Verify it by running perl practice.pl and comparing the output character for character.

Exercise 2 — break it on purpose. Delete the semicolon from the end of your first print and run the file again. Write down which line number the error names and which line the mistake is actually on. Then put the semicolon back.

Exercise 3 — predict before you run. Remove the \n from the first print only. Say in one sentence what the output will look like before running it, then run it and check whether you were right.

Exercise 4 — say which is meant. For each sentence, decide whether it is about Perl the language or Perl the program: (a) "Perl ended the statement at the semicolon." (b) "Perl is installed at /usr/bin/perl." (c) "Perl requires a semicolon between statements." (d) "Perl printed an error and stopped."

10. Summary

• Two things share the name Perl — the language you write, and the interpreter program that runs it. A script is just a text file of instructions for that program.
• Perl was built to replace a pipeline of small tools with one language that could search text, calculate, keep track and write a report in a single program. That is still what it is used for.
• Perl checks the whole file, then runs it. It does not execute line by line, which is why a mistake on a later line can stop an earlier line from printing anything.
• print displays text; quotes delimit it; \n adds a new line; a semicolon ends a statement. Unquoted text such as 72 + 65 is worked out first rather than printed as written.
• An error message names where Perl noticed trouble, not always where it is. Check the line above, and prefer the simplest explanation.
• In chip design, Perl's job is text — reading large logs and reports and turning them into a short, trustworthy answer. Part I builds the skills; Part II does the work.

You now have the execution model and a program you have run yourself. The next chapters answer the two questions that follow immediately: which perl is on the machine you are using, and how to turn a script into something you can run without typing perl in front of it.