Use Perl's Predefined Variables for Safer Scripts

You will finish with a small Perl script that reports its inputs, process identity, environment and failures, plus a practical way to use the variables that Perl fills in for regular expressions and external commands. The examples match the installed perlvar(1) from perl-doc, Perl v5.38.2 on this machine.

Allow about 20 minutes. You need a shell and Perl. Nothing here needs elevated privileges, and the examples only read process state or create temporary files under /tmp. Do not copy an environment-changing example into a long-running service without checking what its child processes should inherit.

1. Confirm the interpreter and inspect the basic inputs

$^V is Perl's version object, $0 is the program name, $$ is the Perl process ID, and @ARGV contains arguments after the program name. Run this read-only probe:

perl -e 'printf "perl=%s pid=%d program=%s\n", $^V, $$, $0; printf "args=%s\n", join("|", @ARGV)' alpha beta

Expected output is similar to this, although the process ID and program name can vary:

perl=v5.38.2 pid=12345 program=-e
args=alpha|beta

Checkpoint: @ARGV starts with alpha, not the command name. Use $0 when you need the name Perl was given. Assigning to $0 can alter what Linux tools such as ps display, but the manpage warns that the visible length and formatting are platform-dependent. It is a status label, not a reliable way to hide a process.

2. Read command-line files with the default variables

$_ is Perl's default input and pattern-searching space. The null filehandle, written as <>, reads the files named in @ARGV, or standard input when no files are supplied. $ARGV records the current filename while that input is being read.

perl -ne 'chomp; print "$ARGV: $_\n" if /ERROR/' application.log

This prints only matching lines, prefixed with their input filename. The -n switch supplies the loop around <>; $_ is the current line and the regular expression uses it implicitly. The same match written explicitly is if ($_ =~ /ERROR/), which is often clearer when a script grows.

Trap: $_ is global in this Perl release. A called function that changes it can affect its caller. Prefer named lexical variables for substantial code, or localise a deliberate temporary change inside a short block:

sub normalised {
    my ($text) = @_;
    local $_ = $text;
    s/\s+/ /g;
    return $_;
}

print normalised("many   spaces"), "\n";

Here @_ is the subroutine's argument array. Its default use by shift and pop is convenient, but naming arguments at the boundary makes data flow easier to follow.

3. Treat the environment as inherited process state

%ENV exposes the current environment. Assigning a value changes what subsequently started child processes receive. Perl 5.18 and later stringify both keys and values stored there, so use strings deliberately:

perl -e '$ENV{APP_MODE} = "check"; print "$ENV{APP_MODE}\n"; system($^X, "-e", "print \$ENV{APP_MODE}, qq{\n}")'

Expected output:

check
check

$^X identifies the Perl executable running the current program, which is safer than assuming that perl resolves to the same interpreter in a child process. Never print the whole %ENV in a bug report: it can contain credentials, tokens and private paths. If a child should not receive a value, remove it with delete $ENV{APP_MODE} before starting that child. This changes only the current process and its future children.

4. Check system calls and child exit status immediately

$! is meaningful immediately after a failed system or library call. Capture or report it in that failure branch, before another operation changes the context:

my $path = "/path/to/input.txt";
open my $fh, "<", $path or die "cannot open $path: $!\n";
close $fh or die "cannot close $path: $!\n";

Do not test $! later to decide whether an earlier successful call worked. The manpage explicitly says a successful call need not clear the C library error value.

For an external command, $? is a wait status, not simply the command's exit number. Decode it after system:

system "sh", "-c", "exit 7";
if ($? == -1) {
    die "could not start command: $!\n";
} elsif ($? & 127) {
    printf "command died from signal %d\n", $? & 127;
} else {
    printf "command exit=%d\n", $? >> 8;
}

Expected output is command exit=7. A non-zero exit is not automatically an operating-system error, and $! is not the right replacement for decoding a command's result.

5. Separate Perl exceptions from external failures

$@ contains the last error caught by eval. It is cleared on a successful evaluation, so check it immediately:

my $value = eval { die "invalid value" };
if ($@) {
    my $error = $@;
    chomp $error;
    print "Perl evaluation failed: $error\n";
}

Warnings are not collected in $@. Also, do not confuse $@ with $?: the former is a Perl exception from eval, while the latter is the status from a waited-for child, pipe close or similar operation.

6. Use regular-expression capture variables carefully

After a successful match, $1, $2 and later numbered variables contain capture groups. The match variables are dynamically scoped and can be overwritten by another regular expression, so copy a value before calling code that may match again:

my $line = "user=alice id=42";
if ($line =~ /user=(\w+) id=(\d+)/) {
    my ($user, $id) = ($1, $2);
    print "user=$user id=$id\n";
}

Expected output is user=alice id=42. In new code, named captures can be clearer, but the predefined numbered variables remain common in small filters and older scripts.