This module is exhaustively documented inline in the standard POD
format. Part of that is excerpted here as a brief summary:

This module presents an OO approach to command lines, allowing you
to instantiate an 'argv object' and run it, e.g.:

    my $ls = Argv->new(qw(ls -l));
    my $rc = $ls->system;	# or $ls->exec or $ls->qx

Which raises the immediate question - what value does this mumbo-jumbo
add over Perl's native support such as:

    my $rc = system(qw(ls -l));

The answer comes in a few parts:

STRUCTURE

First, by recognizing the underlying properties of an arg vector. Every
argv begins with a program name which is followed by (potentially)
options and operands. The object factors its raw argv into these three
groups, and provides accessor methods which allow operations on each
group independently. Or the object can be created with the categories
preset, e.g.

    my $ls = Argv->new('cat', [qw(-n -u)], '/etc/passwd');

as any or all of the categories may be provided as an array ref.

OPTION SETS

Second, the module encapsulates and extends C<Getopt::Long> to allow
parsing of the argv's options into different I<option sets>. This is
useful in the case of wrapper programs which may, for instance, need to
parse out one set of flags which direct the behavior of the wrapper
itself, parse a different set and pass them to program X, then another
for program Y, then exec program Z with the remainder.  Doing this kind
of thing on a basic @ARGV using indexing and C<splice()> is do-able but
leads to spaghetti-ish code and lots of off-by-one errors.  Like most
modules, this one exists to hide the spaghetti.

EXTRA FEATURES

The I<execution methods> C<system, exec, and qx> extend their Perl
builtin analogues in a few ways.  These are described fully in the POD
but generally are in the area of UNIX/Win32 portability. For instance,
they can automatically convert / pathnames to \ on Windows platforms
before exec-ing them, correctly quote command lines that will be
exposed to Windows shell-like parsing in cases where such exposure
wouldn't occur on a Unix platform, cause exec() to behave synchronously
on Windows as it does on Unix, etc.

Since many users may be interested only in these Unix/Windows portability
aids and may not care about having an OO approach to factoring argv's
into option sets, the 'system' and 'exec' methods are also made
available as regular functions which (if imported) override the
builtins. Thus users may find that adding

    use Argv qw(system exec qv);

to an existing UNIX-based script enhances its portability to Windows
(since it's impossible to override the C<qx()> builtin, it's exported
as C<qv()>).