How to Install Perl on Linux

Difficulty: Beginner (with optional Intermediate/Advanced paths)

Relevant tags: perl, linux, installation, package-manager, cpan, cpanminus, perlbrew, modules, build-from-source

Overview

Perl is a mature, widely deployed programming language that is commonly preinstalled on Linux (especially on server distributions) because many system tools and scripts rely on it. Installing Perl on Linux usually falls into one of three approaches:

• Use your Linux distribution’s package manager (recommended for most users and for system scripts).
• Use a user-level Perl version manager like perlbrew (recommended when you need a newer Perl, multiple versions, or isolated environments for applications).
• Build Perl from source (advanced; useful for custom builds, exotic platforms, or reproducible toolchains).

The best choice depends on your goals:

• If you just need Perl to run scripts: install via package manager.
• If you need a specific Perl version (e.g., 5.38+) without impacting OS tools: use perlbrew.
• If you need custom compile options or want a tightly controlled build: compile from source.

Step 1: Check Whether Perl Is Already Installed

Many Linux systems already have Perl. Verify with:

perl -v
which perl
perl -E 'say $^V'

If perl is found and prints a version, you may already be done. If not, follow one of the install methods below.

Method A (Recommended): Install Perl via Your Package Manager

This method integrates with your OS updates, security patches, and dependency management. It’s also the safest approach for system stability, especially on servers where OS utilities may depend on the system Perl.

Debian / Ubuntu

sudo apt update
sudo apt install -y perl

Helpful extras:

# Developer tools often needed to build XS/compiled modules
sudo apt install -y build-essential

# cpanminus (popular CPAN installer)
sudo apt install -y cpanminus

Fedora

sudo dnf install -y perl

Helpful extras:

sudo dnf install -y gcc make perl-App-cpanminus

RHEL / Rocky / AlmaLinux / CentOS Stream

sudo dnf install -y perl

Helpful extras (names can vary by version/repo):

sudo dnf install -y gcc make perl-App-cpanminus

Arch Linux

sudo pacman -Syu
sudo pacman -S perl

Extras:

sudo pacman -S perl-cpanminus base-devel

openSUSE

sudo zypper refresh
sudo zypper install -y perl

Extras:

sudo zypper install -y perl-App-cpanminus gcc make

Alpine Linux

sudo apk add --no-cache perl

Extras:

sudo apk add --no-cache build-base perl-app-cpanminus

Why this method is best (most of the time)

• Security updates arrive via normal OS updates.
• Consistency with other system packages.
• Lower risk of breaking OS tools that assume a particular Perl layout.

Method B: Install Multiple Perl Versions with perlbrew (User-level)

perlbrew installs Perl into your home directory and lets you switch versions without touching the system Perl. This is a best practice for application development when you need a newer Perl than your distro provides, or if you want separate Perls per project.

Typical perlbrew workflow

# Install perlbrew
curl -L https://install.perlbrew.pl | bash

# Initialize shell (add this to ~/.bashrc or ~/.zshrc)
source ~/perl5/perlbrew/etc/bashrc

# Install a specific Perl version (example version)
perlbrew install perl-5.38.2

# Switch to it
perlbrew switch perl-5.38.2

# Confirm
perl -v
which perl

Note: Building Perl requires a compiler toolchain and common libraries. If perlbrew install fails, install build tools first (e.g., build-essential on Debian/Ubuntu, base-devel on Arch, gcc make packages elsewhere).

Best practice with perlbrew

• Do not replace the system Perl. Keep system Perl for OS tooling; use perlbrew Perl for your apps.
• Pin versions (e.g., 5.38.2) for reproducibility.
• Install modules per Perl and avoid mixing module paths between different Perls.

Method C (Advanced): Build Perl from Source

Building from source is useful when you need a customized build (compile flags, unusual filesystem layout, minimal images, custom prefixes) or your distro’s Perl is too old and you don’t want a version manager.

High-level steps

1. Install build dependencies (compiler, make, headers).
2. Download Perl source tarball.
3. Configure with a prefix (often in your home directory).
4. Compile, run tests, install.
5. Update PATH to use the new Perl.

Example build (generic)

# 1) Build tools (Debian/Ubuntu example)
sudo apt update
sudo apt install -y build-essential

# 2) Download and extract (example version)
# (You can download from official Perl sources; version may differ.)
tar xzf perl-5.xx.y.tar.gz
cd perl-5.xx.y

# 3) Configure into your home directory
./Configure -des -Dprefix=$HOME/perl-5.xx.y

# 4) Build + test
make -j"$(nproc)"
make test

# 5) Install
make install

# 6) Use it
export PATH="$HOME/perl-5.xx.y/bin:$PATH"
perl -v

Best practice: Always run make test before make install. Skipping tests can lead to subtle runtime issues later (especially on systems with unusual libc or missing optional libraries).

Installing CPAN Modules (After Perl Is Installed)

Perl’s ecosystem lives on CPAN. After installing Perl, you commonly install modules using one of these approaches:

• Prefer distro packages when available (e.g., libwww-perl on Debian/Ubuntu, perl-LWP-Protocol-https on Fedora/RHEL). This aligns with OS updates.
• Use cpanminus (cpanm) for simple, script-friendly installs.
• Use local::lib to install modules into your home directory without sudo.

Install cpanminus

# Debian/Ubuntu
sudo apt install -y cpanminus

# Fedora/RHEL
sudo dnf install -y perl-App-cpanminus

# Arch
sudo pacman -S perl-cpanminus

Install modules into your home directory (no root) with local::lib

cpanm --local-lib ~/perl5 local::lib

# Add to shell config (~/.bashrc or ~/.zshrc)
eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib=$HOME/perl5)"

Why this matters: Installing modules globally with sudo cpan or sudo cpanm can conflict with distro-managed Perl packages and create hard-to-debug issues. Home installs keep your system clean.

Runnable Perl Examples (With Expected Output)

Example 1: Verify Perl can run code and compute a SHA-256 hash (core module)

use strict;
use warnings;
use Digest::SHA qw(sha256_hex);

my $input = "Perl on Linux\n";
print sha256_hex($input), "\n";

Expected output:

5a7ee957f1622c1fb3fcc64845119b2f08d7ca8490fbd8a48d741b582606b339

This confirms Perl runs correctly and that you have a working core module set.

Example 2: Create a file, read it back, and count lines/words (real-world scripting pattern)

use strict;
use warnings;
use File::Temp qw(tempfile);

my ($fh, $path) = tempfile();
print {$fh} "alpha beta\n";
print {$fh} "beta gamma delta\n";
close $fh;

open my $in, "<", $path or die "open: $!";
my ($lines, $words) = (0, 0);
while (my $line = <$in>) {
  $lines++;
  my @w = grep { length } split /\s+/, $line;
  $words += scalar @w;
}
close $in;

print "lines=$lines words=$words\n";

Expected output:

lines=2 words=5

This is a common pattern for ETL, log processing, and admin scripts.

Example 3: Parse simple web logs from DATA and count HTTP 404s

use strict;
use warnings;

my $count_404 = 0;
while (my $line = <DATA>) {
  # Very simplified log parsing: look for status code as a standalone token
  $count_404++ if $line =~ /\s404\s/;
}
print "404s=$count_404\n";

__DATA__
10.0.0.1 - - [01/Jan/2026:00:00:01 +0000] "GET / HTTP/1.1" 200 123
10.0.0.2 - - [01/Jan/2026:00:00:02 +0000] "GET /missing HTTP/1.1" 404 10
10.0.0.3 - - [01/Jan/2026:00:00:03 +0000] "GET /favicon.ico HTTP/1.1" 404 0

Expected output:

404s=2

This demonstrates quick, practical text processing—one of Perl’s strongest real-world uses on Linux.

Best Practices

• Keep system Perl for the OS: Don’t overwrite it; use perlbrew or a custom prefix for app-specific Perl.
• Use strict and warnings: Start scripts with use strict; use warnings; to catch bugs early.
• Prefer user-level module installs: Use local::lib or perlbrew’s environment to avoid breaking the OS Perl.
• Pin versions for production: Lock your Perl and module versions to prevent surprise changes.
• Automate installs: For servers/containers, script your Perl + module installs to make deployments repeatable.
• Validate environments: Check perl -V, @INC, and ensure you’re installing modules for the correct Perl binary.

Common Pitfalls (and How to Avoid Them)

• Installing modules for the wrong Perl: If you have multiple Perls, cpanm might target a different one. Use the matching cpanm in PATH, or run perl -V and confirm.
• Using sudo with CPAN: Global installs can conflict with OS packages. Prefer local::lib or perlbrew.
• Missing compiler toolchain: Many CPAN modules include XS (C extensions). Install build tools (e.g., build-essential, gcc, make) and relevant -dev/-devel libraries.
• Outdated Perl from distro: Some stable distros ship older versions. If you need newer language features or module requirements, use perlbrew.
• Broken SSL/proxy settings during CPAN installs: Corporate proxies or missing CA certificates can cause fetch failures. Configure proxy env vars and ensure CA certs are installed.
• Assuming non-core modules exist: Not every system has popular modules preinstalled. Document module dependencies and install them explicitly.

Real-World Usage on Linux

• Sysadmin automation: log parsing, user management, backups, reporting.
• Text processing pipelines: transforming data, templating configs, ETL jobs.
• Glue code: integrating command-line tools, APIs, and services.
• Legacy app maintenance: many production systems still rely on Perl scripts and CPAN modules.

Quick Checklist

• Install Perl via package manager (or perlbrew if you need multiple/newer versions).
• Verify with perl -v and run a small script.
• Install cpanm and use local::lib for non-root module installs.
• For production, pin Perl + module versions and automate the setup.

5a7ee957f1622c1fb3fcc64845119b2f08d7ca8490fbd8a48d741b582606b339

(empty)