=over

=item exec LIST
X<exec> X<execute>

=item exec PROGRAM LIST

The L<C<exec>|/exec LIST> function executes a system command I<and never
returns>; use L<C<system>|/system LIST> instead of L<C<exec>|/exec LIST>
if you want it to return.  It fails and
returns false only if the command does not exist I<and> it is executed
directly instead of via your system's command shell (see below).

Since it's a common mistake to use L<C<exec>|/exec LIST> instead of
L<C<system>|/system LIST>, Perl warns you if L<C<exec>|/exec LIST> is
called in void context and if there is a following statement that isn't
L<C<die>|/die LIST>, L<C<warn>|/warn LIST>, or L<C<exit>|/exit EXPR> (if
L<warnings> are enabled--but you always do that, right?).  If you
I<really> want to follow an L<C<exec>|/exec LIST> with some other
statement, you can use one of these styles to avoid the warning:

    exec ('foo')   or print STDERR "couldn't exec foo: $!";
    { exec ('foo') }; print STDERR "couldn't exec foo: $!";

If there is more than one argument in LIST, this calls L<execvp(3)> with the
arguments in LIST.  If there is only one element in LIST, the argument is
checked for shell metacharacters, and if there are any, the entire
argument is passed to the system's command shell for parsing (this is
C</bin/sh -c> on Unix platforms, but varies on other platforms).  If
there are no shell metacharacters in the argument, it is split into words
and passed directly to C<execvp>, which is more efficient.  Examples:

    exec '/bin/echo', 'Your arguments are: ', @ARGV;
    exec "sort $outfile | uniq";

If you don't really want to execute the first argument, but want to lie
to the program you are executing about its own name, you can specify
the program you actually want to run as an "indirect object" (without a
comma) in front of the LIST, as in C<exec PROGRAM LIST>.  (This always
forces interpretation of the LIST as a multivalued list, even if there
is only a single scalar in the list.)  Example:

    my $shell = '/bin/csh';
    exec $shell '-sh';    # pretend it's a login shell

or, more directly,

    exec {'/bin/csh'} '-sh';  # pretend it's a login shell

When the arguments get executed via the system shell, results are
subject to its quirks and capabilities.  See L<perlop/"`STRING`">
for details.

Using an indirect object with L<C<exec>|/exec LIST> or
L<C<system>|/system LIST> is also more secure.  This usage (which also
works fine with L<C<system>|/system LIST>) forces
interpretation of the arguments as a multivalued list, even if the
list had just one argument.  That way you're safe from the shell
expanding wildcards or splitting up words with whitespace in them.

    my @args = ( "echo surprise" );

    exec @args;               # subject to shell escapes
                                # if @args == 1
    exec { $args[0] } @args;  # safe even with one-arg list

The first version, the one without the indirect object, ran the I<echo>
program, passing it C<"surprise"> an argument.  The second version didn't;
it tried to run a program named I<"echo surprise">, didn't find it, and set
L<C<$?>|perlvar/$?> to a non-zero value indicating failure.

On Windows, only the C<exec PROGRAM LIST> indirect object syntax will
reliably avoid using the shell; C<exec LIST>, even with more than one
element, will fall back to the shell if the first spawn fails.

Perl attempts to flush all files opened for output before the exec,
but this may not be supported on some platforms (see L<perlport>).
To be safe, you may need to set L<C<$E<verbar>>|perlvar/$E<verbar>>
(C<$AUTOFLUSH> in L<English>) or call the C<autoflush> method of
L<C<IO::Handle>|IO::Handle/METHODS> on any open handles to avoid lost
output.

Note that L<C<exec>|/exec LIST> will not call your C<END> blocks, nor
will it invoke C<DESTROY> methods on your objects.

Portability issues: L<perlport/exec>.

=back