I just threw together a little module currently named Env::Reject and would 
like a review of the name and concept. In particular, if there's a 
different/better solution than re-execing with a depleted environment I'd 
appreciate hearing about it. I'll just paste in the relevant POD sections 
below.

Thanks in advance,
David Boyce

=head1 NAME

Env::Reject - Reject PERL* environment variables and their semantics

=head1 SYNOPSIS

   use Env::Reject;
   use Env::Reject qw(PERLLIB PERL5LIB);
   use Env::Reject qw(+ PERLLIB PERL5LIB FOO BAR);

=head1 DESCRIPTION

Imagine a commercial product "X" which embeds Perl. The user of this
product shouldn't need to know whether some or all of the code is
written in Perl or C++ or Java; it's a software product, you install
it, and if you're lucky it works.

Now picture a shop that makes heavy use of Perl themselves and which
then buys and installs product X. Since Perl is in such wide use, this
may not be an uncommon scenario.  But it creates a problem: say this
shop tends to make use of the environment variables defined in
perlrun(1), e.g. PERL5LIB or PERL5OPT, for their internal processes.
Now product X begins behaving erratically: it fails when they set
PERL5LIB to point to a test module area, it comes up in the debugger
when they set PERL5OPT=-d. The Perl code embedded within X is sensitive
to the same EV's their own scripts use, and in essence they've lost the
right to use them as they see fit.

This situation is almost impossible for the user to work around on
their own without giving up on the PERL* variables. Nor is it easy for
the vendor to fix. Simply deleting those EV's in their scripts won't do
any good; by the time the script gets control the Perl interpreter has
already made the requested changes.

Env::Reject implements one solution: if a script contains:

     use Env::Reject;

then any EV's matching /^PERL/ will be removed from the env and the
script re-executed in a "clean" environment. If no /^PERL/ variables
are found, script execution proceeds normally.

A limited list of variables can be rejected explicitly:

     use Env::Reject qw(PERLLIB PERL5OPT FOOBAR);

Note: as a convenience, EV's not matching /^PERL/ may be specified as
well (eg FOOBAR above); these will be removed from the environment too
but will not cause a re-exec.

If the first word of the rejection list is "+", e.g.

     use Env::Reject qw(+ PERLLIB);

a message will be printed to the effect that script x is being re-run
after rejecting variables y and z.

Reply via email to