Use perl5282delta to Check a Perl 5.28.2 Upgrade

You will finish with a short, evidence-based check for whether a host is running the Perl release described by perl5282delta, which changes it records, and which historical fixes matter to your scripts. The command is a release-notes document, not a configuration tool: reading it changes nothing.

Allow about fifteen minutes. You need a shell, the perl-doc package, and permission to run ordinary read-only commands. The examples use Debian or Ubuntu package queries where useful, but the Perl probes work on other Unix-like systems. No command in this guide needs sudo.

1. Confirm which release note you are reading

Start by asking Perl's local documentation system where it found the page. This avoids reading a copied file from a different installation:

$ perldoc -l perl5282delta
/usr/share/perl/5.38/pod/perl5282delta.pod
$ perldoc perl5282delta | sed -n '1,18p'
NAME
    perl5282delta - what is new for perl v5.28.2

DESCRIPTION
    This document describes differences between the 5.28.1 release and the
    5.28.2 release.

The local source may be a POD file even when the manpage you normally open is compressed under /usr/share/man. Those are two installed renderings of the same documentation. On this Ubuntu host, both perl-doc and perl-base are version 5.38.2-3.2ubuntu0.6. If perldoc cannot find the page, install the documentation package for your distribution or read the supplied manpage directly with man perl5282delta.

2. Record the running Perl version

Now check the interpreter that your shell will actually execute:

$ command -v perl
/usr/bin/perl
$ perl -e 'printf "Perl %vd\n", $^V'
Perl v5.38.2
$ perl -V:version -V:archname
version='5.38.2';
archname='x86_64-linux-gnu-thread-multi';

Do not describe this host as a Perl 5.28.2 host just because perl5282delta is installed. Release notes remain useful after an upgrade, and the local page is commonly shipped with a much newer Perl. On this machine the page is present with Perl 5.38.2, so the probes below confirm current behaviour rather than proving what an unpatched 5.28.1 interpreter did.

If a service uses a wrapper, virtual environment or container, run the same commands in that execution context. command -v and perl -V describe the shell's interpreter, not every Perl binary on the system.

3. Check the module versions named by the note

The document records three core-module updates: Module::CoreList from 5.20181129_28 to 5.20190419, PerlIO::scalar from 0.29 to 0.30, and Storable from 3.08 to 3.08_01. Ask the interpreter for the versions it loads:

$ perl -MModule::CoreList -e 'print "Module::CoreList $Module::CoreList::VERSION\n"'
Module::CoreList 5.20231129
$ perl -MPerlIO::scalar -e 'print "PerlIO::scalar $PerlIO::scalar::VERSION\n"'
PerlIO::scalar 0.31
$ perl -MStorable -e 'print "Storable $Storable::VERSION\n"'
Storable 3.32

Your values may differ. The useful comparison is between the interpreter used by the application and the minimum version or fix the application needs. A module version printed by a different perl binary is not evidence about the service you are debugging.

4. Test the in-place edit fix without touching real data

One 5.28.2 fix concerns perl -i. When the edit reaches global destruction with a zero exit status, the generated output is now treated as successful and replaces the input file. Test that contract against a disposable file:

$ tmp=$(mktemp /tmp/perl5282delta.XXXXXX)
$ printf '%s\n' old > "$tmp"
$ perl -i -ne 'print "new\n"; last' "$tmp"
$ printf 'status: %s, contents: ' "$?"
status: 0, contents: new
$ printf '\n'

The command edits only the file named by $tmp. It does not change a Perl setting or a service. The exit status is the important part: a successful edit produced replacement content.

There is a sharp boundary here. Do not adapt this first test to a production configuration file. In-place editing is destructive if the program emits incomplete output, and an error path must be checked separately. The documented failing shape uses die, which should leave the original file unreplaced:

$ tmp=$(mktemp /tmp/perl5282delta-fail.XXXXXX)
$ printf '%s\n' original > "$tmp"
$ perl -i -ne 'print "partial\n"; die "stop\n"' "$tmp"
stop
$ printf 'status: %s, contents: ' "$?"
status: 255, contents: original
$ printf '\n'

The precise non-zero status can vary with the failure, but the original content should remain. If you must recover a real in-place edit, restore the file from version control or a tested backup. There is no general undo command for perl -i.

5. Understand the Unicode compatibility change

The release note also changes regular-expression script-run handling. Digits from the Common Unicode script, including fullwidth digits, may occur in a run of another script, but all digits in that run still need to come from the same ten-digit set. This matters to validation code that uses Unicode properties, not to ordinary ASCII-only matching.

Use a small probe when checking an application on the current interpreter:

$ perl -e 'my $s = "\x{03B1}\x{FF11}\x{FF12}"; print(($s =~ /\A\p{Greek}+[\p{Greek}\p{Common}]+\z/ ? "match\n" : "no match\n"))'
match

This verifies that the current interpreter accepts Greek text followed by fullwidth digits for this pattern. It does not certify an entire input-validation policy. Test mixed digit sets, normalise input where your application requires it, and keep the exact Perl version in the test record.

6. Treat platform notes as build history

The Windows note concerns an old Server 2003 SP1 SDK build. The Mac OS X note concerns shared-library builds, System Integrity Protection and the path to libperl.dylib. These are build and test concerns, not switches to add to a Linux command line.

Read those sections when you maintain the affected build pipeline. On a Linux runtime, the practical action is to record the platform and build configuration alongside perl -V, then reproduce a suspected problem in the same build environment. Do not set DYLD_LIBRARY_PATH on Linux as a guess; it is the Mac-specific variable named by the note.

7. Report a real regression with enough evidence

If a small test still fails on a supported installation, reduce it to the smallest case that demonstrates the failure. Capture the output of perl -V, the exact command, input data and exit status. The manpage points to the Perl bug database and to perlbug; do not send confidential input or security-sensitive details to a public tracker. Follow the security contact guidance in perlsec for vulnerabilities.