Developers hate writing documentation. They'd hate it even more if their
computer tattled on them, but maybe they'll be even more thankful in the long
run. Even if not, perlmodstyle tells you to, so you must obey.
This module provides a mechanism for determining if the pod for a given module
is comprehensive.
This is a specialized POD viewer to extract embedded tests and code
examples from POD. It doesn't do much more than that. pod2test does the
useful work.
After creating a Pod::Tests object, you parse the POD by calling one of
the available parsing methods documented below. You can call parse as many
times as you'd like, all examples and tests found will stack up inside the
object.
Once extracted, the tests can be built into stand-alone testing code using
the build_tests() and build_examples() methods. However, it is recommended
that you first look at the pod2test program before embarking on this.
Pod::Usage provides the function "pod2usage()" to print usage messages for a
Perl script based on its embedded pod documentation. Pod::Usage is a subclass of
Pod::PlainText. Please see the POD documentation for this module (embedded in
the file "Usage.pm") for more details. The pod2usage() function is probably the
most generally useful function in this entire distribution since it is useful to
just about any Perl5 script that is invoked from the command-line.
This is a generic interface for placing processes in the background on
both Unix and Win32 platforms. This module lets you start, kill, wait
on, retrieve exit values, and see if background processes still exist.
Proc::Daemon provides a method for a Perl script to run as a Unix
daemon process.
This module provides an intuitive, Perl-ish way to write forking
programs by letting you use blocks to illustrate which code section
executes in which fork. The code for the parent, child, retry handler
and error handler are grouped together in a "fork block". The clauses
may appear in any order, but they must be consecutive (without any other
statements in between).
Proc::Pidfile is a very simple OO interface which manages a pidfile
for the current process. You can pass the path to a pidfile to use as
an argument to the constructor, or you can let Proc::Pidfile choose
one (basically, "/var/run/$basename", if you can write to /var/run,
otherwise "/$tmpdir/$basename").
This module is a first crack at providing a consistent interface to
Unix (and maybe other multitasking OS's) process table information.
The impetus for this came about with my frustration at having to parse
the output of various systems' ps commands to check whether specific
processes were running on different boxes at a large mixed Unix site.
The output format of ps was different on each OS, and sometimes
changed with each new release of an OS. Also, running a ps subprocess
from within a perl or shell script and parsing the output was not a
very efficient or aesthetic way to do things.
With this module, you can do things like this:
# kill memory pigs
use Proc::ProcessTable;
$t = new Proc::ProcessTable;
foreach $p ( @{$t->table} ){
if( $p->pctmem > 95 ){
$p->kill(9);
}
}
Proc::Wait3 module implements wait3 system call in Perl.
If any child processes have exited, this call will "reap" the zombies
similar to the perl "wait" function. By default, it will return
immediately and if there are no dead children, everything will be
undefined. If you pass in a true argument, it will block until a child
exits (or it gets a signal).
Proc::WaitStat contains functions for interpreting and acting on
wait status values.