How to Install Perl on Windows 10 (Strawberry Perl, ActivePerl, and Common Pitfalls)

Category: Programming / Developer Tools
Tags: perl, windows-10, installation, strawberry-perl, activestate, cpan, path, powershell, cmd
Difficulty: Beginner

Perl runs very well on Windows 10, but the “right” installation depends on what you plan to do:

• General development (recommended for most people): Strawberry Perl (includes a compiler toolchain, so many CPAN modules that need compiling “just work”).
• Enterprise-managed environments / vendor tooling: ActivePerl (from ActiveState) may be preferred where policy, support, and curated packages matter.
• Linux-like workflows: WSL (Windows Subsystem for Linux) is an option, but it’s not “native Windows Perl”; it’s Perl inside a Linux environment.

Below is a thorough, practical guide to installing Perl on Windows 10, validating it, installing modules, and avoiding the most common Windows-specific pitfalls.

Option A (Recommended): Install Strawberry Perl

Why Strawberry Perl? On Windows, many CPAN modules (especially those with XS/C code) require a C compiler and build tools. Strawberry Perl bundles a MinGW toolchain and a CPAN client, making it the most “batteries included” experience for typical Perl dev.

1) Download the installer

1. Go to the Strawberry Perl download page.
2. Choose 64-bit unless you specifically need 32-bit for legacy reasons.
3. Download the MSI installer (easiest for Windows).

2) Run the installer

• Accept the license and choose an install location (the default is usually fine).
• Important: enable the option to add Perl to your PATH (if presented).
• If you do not have admin rights, you may need a per-user install or to ask IT to install it.

3) Verify installation (Command Prompt and PowerShell)

Open a new terminal (PATH changes won’t always apply to already-open windows) and run:

perl -v
where perl

You should see Perl’s version info and a path like C:\Strawberry\perl\bin\perl.exe.

4) Test “hello world” quickly

perl -e "print \"Hello from Perl on Windows 10!\\n\""

Option B: Install ActivePerl (ActiveState)

Why ActivePerl? Some organizations standardize on ActiveState for policy, reproducibility, or support. It can be a good choice, but note:

• Some CPAN modules that require compilation can be harder unless your environment includes build tools.
• Package management may differ from the typical “cpan/cpanm everywhere” approach, depending on your ActiveState setup.

Basic steps:

1. Download ActivePerl for Windows (match 64-bit vs 32-bit to your system and needs).
2. Install and ensure it is added to PATH.
3. Validate with perl -v and where perl.

Option C: Use WSL (Linux Perl on Windows)

If you want a Linux environment (Ubuntu, Debian, etc.) with Linux paths and tools, WSL can be excellent. You install Perl inside WSL using the distro package manager (e.g., apt install perl). This is great for server parity, but be aware you are no longer using native Windows paths and Windows Perl modules like Win32::* may not apply.

Best Practices After Installing Perl

1) Know which Perl you are running (PATH hygiene)

Windows can easily end up with multiple Perls (Strawberry, Git-for-Windows perl, Cygwin, old corporate installs). Always confirm:

where perl
perl -V

Best practice: keep exactly one “primary” Perl on PATH, or use a version manager like berrybrew (Windows-friendly Perl version manager) if you truly need multiple.

2) Prefer installing modules without admin rights (local::lib)

Installing CPAN modules system-wide can require admin privileges and can be risky on locked-down machines. A safer approach is per-user installs via local::lib.

High-level workflow:

• Install local::lib from CPAN.
• Initialize it so your environment uses a user-specific module directory.
• Then install modules normally, and they land in your user directory.

3) Use cpanminus when possible

cpan is built-in and works, but cpanm is often simpler and more predictable. Once Perl is installed, you can typically do:

cpan App::cpanminus
cpanm --version

Tip: If module installs fail, re-check you installed Strawberry Perl (with build tools) and that you’re not accidentally running another Perl from somewhere else on PATH.

4) Pick a good editor setup

• VS Code with a Perl extension (syntax highlighting, formatting, linting) is a common choice.
• Use perltidy for consistent formatting (installable from CPAN).
• Use perlcritic (optional) to enforce style rules.

Common Pitfalls (and How to Avoid Them)

Pitfall 1: “perl is not recognized …”

This means Perl’s bin directory isn’t on PATH, or you opened the terminal before installing.

• Close and reopen Command Prompt/PowerShell.
• Re-run installer and enable “add to PATH”, or manually add something like C:\Strawberry\perl\bin.

Pitfall 2: You have multiple Perls and the wrong one runs

Run where perl. If you see multiple entries, Windows will use the first one on PATH. Reorder PATH or remove the unintended one.

Pitfall 3: CPAN module installs fail due to compilation (XS modules)

Many modules include C/XS code and must compile during installation. Strawberry Perl usually handles this because it ships with a toolchain. ActivePerl installations without build tools often struggle here.

• Fix: Prefer Strawberry Perl for development.
• Fix: Install a suitable C build toolchain if you must stay on a Perl without one.

Pitfall 4: Proxy/TLS issues when downloading from CPAN

Corporate proxies can break CPAN downloads. You may need to configure proxy settings for CPAN clients, or use an internal mirror if your organization provides one.

Pitfall 5: Quoting differences in PowerShell vs CMD

One-liners that work in cmd.exe may need different quoting in PowerShell. If a one-liner behaves strangely, put the code in a .pl file and run perl script.pl to avoid shell quoting issues.

Pitfall 6: File associations and double-click behavior

Double-clicking a .pl file may open it in an editor or flash a console window and close instantly. Prefer running scripts from a terminal so you can see output and errors:

perl your_script.pl

Runnable Perl Code Examples (with Expected Output)

All examples below use only core Perl modules, so they should run immediately after a standard install.

Example 1: Confirm Perl is working (simple output)

use strict;
use warnings;

print "Perl is installed and running.\n";
print "OK\n";

Expected output:

Perl is installed and running.
OK

Example 2: JSON round-trip using core JSON::PP

use strict;
use warnings;
use JSON::PP qw(encode_json decode_json);

my $data = {
  os      => "Windows",
  version => 10,
  tools   => ["perl", "cpan"],
};

my $json = encode_json($data);
print "JSON: $json\n";

my $decoded = decode_json($json);
print "Decoded os=$decoded->{os}, version=$decoded->{version}\n";

Expected output (format may vary slightly, but content is the same):

JSON: {"os":"Windows","version":10,"tools":["perl","cpan"]}
Decoded os=Windows, version=10

Example 3: Parse command-line flags (core Getopt::Long)

Save as greet.pl:

use strict;
use warnings;
use Getopt::Long qw(GetOptions);

my $name = "World";
GetOptions(
  "name=s" => \$name,
) or die "Usage: perl greet.pl --name YourName\n";

print "Hello, $name!\n";

Run:

perl greet.pl --name Ada

Expected output:

Hello, Ada!

Final Checklist

• Install: Strawberry Perl (recommended) or ActivePerl (org-specific).
• Verify: perl -v and where perl.
• Run scripts: from a terminal using perl your_script.pl.
• Modules: consider local::lib and cpanm for smoother installs.
• Avoid confusion: ensure only the intended Perl is first on PATH.

Perl is installed and running.
OK

(empty)