Verify a Perl installation with perlivp

Use perlivp to check that the Perl executable, its library paths, required modules, extensions and installed module files agree with the Perl build. On this machine the command is from Perl 5.38.2 and completes with six numbered checks. The procedure is read-only: it diagnoses an installation, but it does not repair one.

Allow about five minutes. You need a shell and the perl package installed. You do not normally need sudo. If you are checking a separate Perl installation, run the matching perlivp from that installation rather than mixing executables and libraries from different builds.

1. Confirm which Perl you will check

First resolve both commands and record the interpreter version. This catches a common distraction: a shell path can select one Perl while you are thinking about another one.

command -v perlivp
command -v perl
perl -v

On the reference system, the paths are /usr/bin/perlivp and /usr/bin/perl, and the version is Perl 5.38.2. The installed Debian package is perl 5.38.2-3.2ubuntu0.6. Your output may differ after an upgrade or when a locally built Perl appears earlier in PATH.

2. Run the normal verification

Run the procedure without options for the compact result. It should print one ok line for each successful group and return status zero.

perlivp
printf 'exit=%s\n' "$?"

A healthy installation ends with output similar to this:

ok 1 Executable perl binary
ok 2 Perl version correct
ok 3 @INC directories exist
ok 4 Modules needed for rest of perlivp exist
ok 5 All (and only) expected extensions installed
ok 6 Module files correctly installed
All tests successful.
exit=0

The exact module list is longer than this summary. The important distinction is between the visible ok lines and the process status: use the status in scripts and monitoring, not a visual search for the word ok.

3. Add context when a check fails

Use -p to print a short description before each test and -v to show more detail after it. They are diagnostic switches; they do not enable extra repairs or change Perl.

perlivp -p -v

On a passing run, the preface names checks such as the Perl binary, the Perl version, every directory in @INC, modules needed by perlivp, built extensions and installed module files. The command still finishes with numbered ok results. Failed tests print extra information even without -v, but the verbose form makes a first investigation easier.

The option letters can be combined, as above. The installed command accepts -p, -v and -h; it does not take an arbitrary long option spelling. To see the local usage text:

perlivp -h

4. Map the failure to the right repair

Read the diagnostic before changing anything. The test groups point to different classes of installation fault.

• Executable check: the Perl path selected by the procedure does not appear executable. Check permissions and whether the installation is complete.
• Version check: the installed interpreter is not the version this perlivp was built to test. This often means commands from two Perl installations are being mixed.
• @INC check: a library directory recorded by Perl is missing. Inspect the reported path and the installation layout before rebuilding or reinstalling.
• Needed modules: Config.pm or ExtUtils::Installed, which perlivp needs to run, is unavailable or incomplete. Treat this as a serious installation problem.
• Expected extensions: an expected module could not be loaded, or an unexpected module named bLuRfle appeared. The latter is a deliberate sentinel check, not a module you should install.
• Module files: validation found files missing from the installation. Preserve the diagnostic and compare it with the package manager's file list or the original Perl installation source.

Do not copy a missing module from an unrelated Perl version into place. That can turn a clear installation error into a mixed tree that is harder to remove and diagnose. Prefer reinstalling the distribution package or repeating the original Perl build and install procedure, following your operating system's normal package or source-build workflow.

5. Re-run after a repair

Repairs are outside perlivp. If you reinstall the distribution package, rebuild Perl, or restore its library tree, run the same checks again in the same shell:

command -v perl
perl -v
perlivp -p -v
printf 'exit=%s\n' "$?"

That sequence verifies the interpreter and the verification program you are now using. A successful rerun should again show six ok groups and exit status zero. If the version check still fails, stop and resolve the path or build mismatch rather than repeatedly reinstalling modules.

Done means

• command -v perl and command -v perlivp identify the intended installation.
• perl -v reports the version you expected.
• perlivp -p -v reports six successful checks, ending with All tests successful..
• The command's exit status is 0.
• Any repair was performed through the normal package or Perl build process, not by copying isolated module files.