=over

=item kill SIGNAL, LIST

=item kill SIGNAL
X<kill> X<signal>

Sends a signal to a list of processes.  Returns the number of arguments
that were successfully used to signal (which is not necessarily the same
as the number of processes actually killed, e.g. where a process group is
killed).

    my $cnt = kill 'HUP', $child1, $child2;
    kill 'KILL', @goners;

SIGNAL may be either a signal name (a string) or a signal number.  A signal
name may start with a C<SIG> prefix, thus C<FOO> and C<SIGFOO> refer to the
same signal.  The string form of SIGNAL is recommended for portability because
the same signal may have different numbers in different operating systems.

A list of signal names supported by the current platform can be found in
C<$Config{sig_name}>, which is provided by the L<C<Config>|Config>
module.  See L<Config> for more details.

A negative signal name is the same as a negative signal number, killing process
groups instead of processes.  For example, C<kill '-KILL', $pgrp> and
C<kill -9, $pgrp> will send C<SIGKILL> to
the entire process group specified.  That
means you usually want to use positive not negative signals.

If SIGNAL is either the number 0 or the string C<ZERO> (or C<SIGZERO>),
no signal is sent to the process, but L<C<kill>|/kill SIGNAL, LIST>
checks whether it's I<possible> to send a signal to it
(that means, to be brief, that the process is owned by the same user, or we are
the super-user).  This is useful to check that a child process is still
alive (even if only as a zombie) and hasn't changed its UID.  See
L<perlport> for notes on the portability of this construct.

The behavior of kill when a I<PROCESS> number is zero or negative depends on
the operating system.  For example, on POSIX-conforming systems, zero will
signal the current process group, -1 will signal all processes, and any
other negative PROCESS number will act as a negative signal number and
kill the entire process group specified.

If both the SIGNAL and the PROCESS are negative, the results are undefined.
A warning may be produced in a future version.

See L<perlipc/"Signals"> for more details.

On some platforms such as Windows where the L<fork(2)> system call is not
available, Perl can be built to emulate L<C<fork>|/fork> at the
interpreter level.
This emulation has limitations related to kill that have to be considered,
for code running on Windows and in code intended to be portable.

See L<perlfork> for more details.

If there is no I<LIST> of processes, no signal is sent, and the return
value is 0.  This form is sometimes used, however, because it causes
tainting checks to be run, if your perl support taint checks.  But see
L<perlsec/Laundering and Detecting Tainted Data>.

Portability issues: L<perlport/kill>.

=back