Installing Perl and Finding the Interpreter

Part I · Module 1 · Chapter 1.2 · Installing Perl and Finding the Interpreter

1. Why This Comes Before Any Code

You could skip straight to writing a script. Engineers who do that lose an afternoon later, for one of two reasons.

The first is that the script ran on their machine and not on the build server, because the two had different Perls. The second is harder: the script ran in both places and produced different answers, because a feature it used behaves differently in an older version. Neither problem is about Perl the language. Both are about which copy of the interpreter was in use, and both are cheap to rule out before you start.

So this chapter has one practical goal: be able to say, out loud and with evidence, which perl runs when you type perl, and what version it is.

2. The Language, and the Copy on Your Machine

Chapter 1.1 separated two things that share the name Perl: the language, which is a set of rules, and the interpreter, which is a program that reads your file and carries out its instructions.

That distinction now becomes practical. The language has versions — Perl 5 has been the current line for a long time, and the language gained features over that time. The interpreter on a given machine is one specific build of one specific version, installed at one specific path. A machine can have several, installed by different people for different reasons.

So "do I have Perl?" is really three questions, and this chapter answers each one with a command:

1. Is there a perl I can run at all? (§3)
2. Which perl is it — where does it live? (§4)
3. What version is it? (§5)

3. Is Perl Already There?

Type this at your shell prompt. The -v asks Perl to report itself and exit without running any program:

perl -v

On the machine these notes were written on — macOS, with the Perl that ships with the system — that prints:

This is perl 5, version 34, subversion 1 (v5.34.1) built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)

Your numbers and the text after built for will differ, because they describe your machine rather than mine. What matters is that something like this appeared: that means a working Perl is on your path.

If Perl is not available, you get a message from your shell rather than from Perl, and the wording depends on which shell you use:

/bin/sh: perl: command not found
/bin/bash: perl: command not found
zsh:1: command not found: perl

Note what that message is telling you. It is not "Perl is broken" and not even quite "Perl is not installed" — it is "I looked everywhere I was told to look and found nothing called perl." Those are different problems with different fixes, and §8 separates them. §6 covers the case where it really is absent.

4. Which perl Will Actually Run

When you type perl, the shell does not search your whole disk. It looks through a list of directories, in order, and uses the first match it finds. That list is called your PATH.

This is the single most useful idea in the chapter. If two Perls are installed, the one earlier in your PATH wins, and nothing announces that to you.

To see which one you would get, use command -v. It is part of the shell itself, so it is available wherever you have a POSIX shell — sh, bash and zsh all have it:

command -v perl

/usr/bin/perl

/usr/bin/perl is what this machine answered. It is not a universal answer. Perl is commonly found at /usr/bin/perl or /usr/local/bin/perl, and on engineering sites it is very often somewhere else entirely, under a shared tools directory. Always ask; never assume the path.

Two related commands are worth knowing:

type perl        # a shell builtin; also tells you HOW the name resolved
which perl       # a separate program, present on most Unix-like systems

perl is /usr/bin/perl
/usr/bin/perl

Prefer command -v in anything you write down or share. which is a separate program rather than part of the shell: it is present on most Unix-like systems but is not guaranteed, and its exact behaviour and output differ between systems. type is a builtin like command -v, and is useful because it reports how the name resolved rather than only where.

On Windows the idea is identical and the commands differ. In cmd.exe the equivalent is where perl; in PowerShell it is Get-Command perl. These were reviewed against their documented behaviour but not executed, because this chapter was written on macOS.

5. Reading the Version

perl -v already printed the version in §3. Read it like this: v5.34.1 means Perl 5, version 34, patch level 1. The leading 5 has been constant for decades; the middle number is the one that matters when someone asks "what Perl have you got?".

If you want only that string — for pasting into a bug report, say — ask for it directly:

perl -V:version

version='5.34.1';

perl --version also works and prints the same banner as perl -v.

Why does the number matter? Because a feature added in one version does not exist in the one before it, and a script using it fails on the older interpreter with an error that does not obviously say "your Perl is too old". You do not need to memorise which feature arrived when. You need to know how to find out what you are running, which you now do.

6. If Perl Is Missing

On most Linux distributions and on macOS, Perl is already present — it is used by parts of the system itself, which is why perl -v so often just works. A missing Perl is more likely on a minimal container image or a fresh Windows machine.

The established ways to get it:

• Linux — install it with your distribution's package manager, as the perl package. On Debian and Ubuntu that is apt; on Fedora and RHEL, dnf. Which command and which package names exist depends on the distribution and its version.
• macOS — a system Perl ships with the OS. If you want a newer one alongside it, Homebrew provides a perl formula.
• Windows — Strawberry Perl is the usual choice: a single installer that provides Perl and the supporting tools, and puts perl on your PATH for you.
• Any system, without administrator rights — perlbrew installs a Perl inside your own home directory. This matters on a shared workstation where you cannot install anything system-wide.

Two honest cautions. First, this chapter deliberately does not reproduce installer output. What a package manager prints varies by distribution, version and mirror, and a transcript copied from somewhere else would teach you to expect the wrong thing. Run the command and read what your own system says. Second, on a managed engineering machine, do not install a second Perl before asking. §9 explains why that can break more than it fixes.

Whatever route you take, the check that it worked is the same: perl -v should answer.

7. Proving It Works

A version banner proves the program starts. It does not prove it can run a program. One line does:

perl -e 'print "Perl works\n"'

Perl works

Every piece of that is something you already met in Chapter 1.1, plus one new flag:

• -e means "the program is right here on the command line, not in a file." It is how you run a one-off without saving anything.
• print, the double-quoted text, and \n are exactly as in 1.1: display this text, and end the line.
• The single quotes around the whole program are for the shell, not for Perl. They stop the shell from interpreting anything inside, so Perl receives the text exactly as you typed it — which is why the double quotes survive to reach Perl.

If that printed Perl works, your interpreter reads a program, compiles it and runs it. You are ready for Chapter 1.3, which puts the same instruction in a file.

8. When It Does Not Work: PATH and Environment

Three situations look identical from the outside and have different causes.

perl: command not found, but you know Perl is installed. Then it is not on your PATH, or not on the PATH of this shell. Print the list the shell is searching:

echo "$PATH" | tr ':' '\n'

That prints one directory per line, in the order they are tried. If the directory holding Perl is not in that list, the shell will never find it, no matter how correctly it is installed. You can confirm the program is really there by running it with its full path — /usr/local/bin/perl -v, substituting the path you actually expect.

It works when you log in, but not inside a script or a scheduled job. This is the most common version of the problem on engineering machines, and it surprises people. A login shell reads your start-up files; a script, a job runner or a tool's internal shell often does not, so it can have a different and much shorter PATH. The symptom is a command that works when you type it and fails when something else runs it. Chapter 1.4 shows the line you put at the top of a script to name the interpreter explicitly, which is part of the answer.

You get a Perl, but not the one you expected. Nothing is broken — the PATH order from §4 is doing exactly what it is designed to do. Run type -a perl to see every candidate in order, and you will see which one is winning.

9. Why Engineers Check Which Perl They Got

A short piece of context, so the commands above have a reason to exist. The depth belongs to Part II.

On a shared Linux workstation in a chip-design group, several Perls commonly coexist: the one the operating system installed and depends on, a newer one a team installed for its own scripts, and sometimes one bundled inside a vendor's design tool. All three are called perl. Which one you get depends on the PATH you happen to have, which in turn depends on how you logged in and which project setup you sourced.

That leads to three practical habits:

• Record the interpreter, not just the script. "It worked for me" is not reproducible. "It worked with the perl at this path, version this" is.
• Expect the project to choose for you. Many groups have a setup step that puts an approved Perl first on your PATH, precisely so that everyone on the project runs the same one. If a project has that, use it rather than your own.
• Leave the system Perl alone. Parts of a Linux system are written in Perl and run with the system interpreter. Replacing or upgrading it to suit one script is how an afternoon becomes a week. Install alongside, or ask the people who own the machine.

None of this requires you to understand design tools yet. It requires only the idea that the interpreter is a specific file on a specific machine — which is what you have just finished proving.

10. What You Should Be Able to Say Now

1. perl -v reports whether a working Perl is on your PATH, and which version it is.
2. command -v perl reports which perl you would get; the path varies by machine and is never safe to assume.
3. The shell searches PATH in order and takes the first match, so with two Perls installed, order decides.
4. perl -e '...' runs a program given on the command line, which proves the interpreter can actually run code.
5. command not found comes from your shell, not from Perl, and means "not on my PATH" rather than necessarily "not installed".
6. A login shell and a script can have different PATHs, which is why something can work when typed and fail when run by a job.

11. Exercise

All four use only commands from this chapter. Nothing needs installing, and nothing changes your machine.

Exercise 1 — identify your interpreter. Run perl -v and command -v perl, and write down one sentence naming both the version and the full path. If command -v printed nothing, note that instead and go to Exercise 4.

Exercise 2 — count your Perls. Run type -a perl. How many lines came back? Say which one perl would use, and how you know from the output alone.

Exercise 3 — read your PATH. Run echo "$PATH" | tr ':' '\n'. Find the line containing the directory that command -v perl reported. Is it near the top or the bottom, and what would happen to §4's answer if another perl existed in a directory above it?

Exercise 4 — prove it end to end. Run perl -e 'print "Perl works\n"'. Then change the message to your own name and run it again. Finally, predict what happens if you remove the \n, then run it and compare with what you predicted — Chapter 1.1 §7 covers why.

12. Summary

• The useful question is not "is Perl installed" but "which Perl am I running". perl -v answers the first; command -v perl answers the second.
• The shell takes the first match on PATH. With more than one Perl installed, PATH order silently decides which one you get, and type -a perl shows the whole list.
• No path is the expected path. /usr/bin/perl is what one machine reported; ask your own rather than assuming.
• Prefer command -v — it is part of the shell. which is a separate program, usually present but not guaranteed and not uniform.
• perl -e '...' is the real test, because it proves the interpreter can compile and run a program rather than merely start.
• command not found is the shell speaking, and a login shell's PATH is not always a script's PATH.
• On a shared engineering machine, the project usually chooses the interpreter. Use what it sets up, record what you used, and leave the system Perl alone.

Next, Chapter 1.3 takes the one-liner from §7, puts it in a file, and runs that file — the edit-save-run cycle every later chapter assumes.