Use perl5181delta to Check a Perl 5.18.1 Upgrade

You will finish with a small, repeatable check for Perl 5.18.1 changes: identify the interpreter and documentation actually installed, review the relevant fixes, and run harmless smoke tests for code that depends on regular expressions, lexical subroutines or debugger behaviour. The guide uses the local perl5181delta(1) document, which describes the difference between Perl 5.18.0 and 5.18.1.

Allow about 15 minutes. You need a shell, Perl and the perl-doc package. The commands are read-only apart from creating no files, and do not require sudo. Do not treat this document as a reason to install an old interpreter on a production host: the machine here has Perl 5.38.2, so its results show current behaviour rather than proving what an unpatched 5.18.0 binary did.

1. Record the interpreter and package version

Start with the executable that is first on your path. This prevents a common upgrade mistake: reading one Perl's documentation while running another Perl.

$ command -v perl
/usr/bin/perl
$ perl -V:version -V:archname -V:useithreads
version='5.38.2';
archname='x86_64-linux-gnu-thread-multi';
useithreads='define';
$ dpkg-query -W -f='${Package} ${Version}\n' perl perl-doc
perl 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

Your paths and package revision can differ. Keep this output with your test result. The archname and useithreads fields matter when investigating platform-specific or threaded-runtime issues; they do not turn a release note into a compatibility guarantee.

2. Open the matching delta document

perl5181delta is documentation, not a program that changes Perl. Ask perldoc where it found the local copy, then read it as plain text:

$ perldoc -l perl5181delta
/usr/share/perl/5.38/pod/perl5181delta
$ perldoc -t perl5181delta | sed -n '1,35p'
NAME
    perl5181delta - what is new for perl v5.18.1

DESCRIPTION
    This document describes differences between the 5.18.0 release and the
    5.18.1 release.

Checkpoint: the document must say that it covers 5.18.0 to 5.18.1. The installed path may sit under a newer Perl tree because distribution packages commonly ship historical documentation together. That path does not mean the running interpreter is Perl 5.18.1.

3. Separate release scope from current behaviour

The delta reports no intentional incompatibilities with 5.18.0. Its practical value is a list of corrected defects, not a list of new command-line switches. It records updates to B, Digest::SHA and Module::CoreList, build fixes for AIX and MidnightBSD, and runtime fixes covering regular expressions, dual-valued variables, XSUB calls, UTF-8 interpolation, lexical subroutines and the debugger.

Do not claim that a current Perl reproduces the old bug. Perl 5.38.2 is newer than the release under discussion and may contain later fixes. Use the notes to decide what to test, then record the exact interpreter used for the test. If an application must support Perl 5.18, test with that supported runtime in an isolated environment rather than downgrading the host.

4. Smoke-test the regular-expression fix

One 5.18.0 regression misread the hash in a bracketed character class followed by a code block when the /x modifier was used. This read-only test checks that the expression matches and that the code block is parsed:

$ perl -e '$_ = "[#]"; print "matched\n" if /[#](?{ 1 })/x'
matched

On the installed Perl, matched is the expected result. This is a syntax and behaviour smoke test, not a performance test and not evidence about a different Perl binary. Keep code blocks in test-only snippets; they are an advanced regular-expression feature and can make patterns harder to audit.

5. Smoke-test lexical-subroutine syntax

The release notes mention crashes and prototype handling around lexical subroutines. A minimal constant subroutine test exercises the supported syntax without changing system state:

$ perl -we 'use feature "lexical_subs"; no warnings "experimental::lexical_subs"; my sub answer() { 42 }; print answer, "\n"'
42

If your application uses lexical subroutines, expand this into its real test suite. Include calls with and without parentheses where prototypes matter, syntax-error tests in a subprocess, and any code that undefines a lexical subroutine. A successful one-line smoke test cannot establish that a large application is safe.

6. Check UTF-8 and debugger-sensitive code deliberately

The delta also describes a malformed-pattern regression when upgraded and downgraded UTF-8 strings were interpolated together. This small check confirms that the current interpreter can match the combined pattern:

$ perl -we 'my $u = "\x{e5}"; my $d = "\x{e5}"; utf8::upgrade($u); utf8::downgrade($d); print "match\n" if ($u . $d) =~ /$u$d/'
match

Use real input and encoding tests for an application that handles non-ASCII data. Do not paste untrusted text into a regular expression without deciding how it should be quoted and encoded.

For debugger regressions, use a disposable checkout and the application's normal test command. The document says that the debugger's man, doc and perldoc commands were repaired and that @_ became visible again. Starting a debugger can execute program code, so do not run it against an untrusted script or with production credentials. There is nothing to undo in the examples above: each Perl process exits without modifying files or services.

7. Turn the result into an upgrade decision

Compare the recorded interpreter with the runtime your application promises to support. If it is newer than 5.18.1, report the delta as historical context and rely on the newer runtime's own release notes for remaining risks. If it is 5.18.0, plan an upgrade before depending on the corrected behaviour. If it is older, read the intervening perl*delta documents as well.

When reporting a suspected Perl core defect, reduce it to a tiny test case and capture perl -V, as the local document recommends. Do not send secrets or production data. Security-sensitive core reports should use the Perl security reporting route named by the documentation, not a public bug report.