From a users perspective, it is a good thing to know that the test script is not going to do anything odd with your personel system/data.

That's not what taint mode does, though -- it flags external data, not internal data. A test script could very well do this evil thing:

WARNING -- Don't try this at home.

#!/usr/bin/perl -T

#### DO NOT ACTUALLY RUN THIS CODE ####

use Test::More tests => 1;
use File::Path;
use File::Spec;

my $n = rmtree( File::Spec->rootdir(), 0, 1);

ok( $n, "Deleted at least one file from the root directory" );
[download]

Sadly, Perl doesn't have a nice sandbox like Java. Good reason not build/test modules as root, eh?

What the taint flag will do is limit the directories in @INC. From perlsec:

When the taint mode ("-T") is in effect, the "." directory is removed from @INC, and the environment variables "PERL5LIB" and "PERLLIB" are ignored by Perl. You can still adjust @INC from outside the program by using the "-I" command line option as explained in perlrun. The two environment variables are ignored because they are obscured, and a user running a program could be unaware that they are set, whereas the "-I" option is clearly visible and therefore permitted.

For testing, I'm still not sure if that is or isn't desireable. What if a user has their own private installation in PERL5LIB?

For testing, I'm still not sure if that is or isn't desireable. What if a user has their own private installation in PERL5LIB?

Then make test fails because the current setup will not work under taint. Which is better then letting CPAN install it, and then find out your program isn't going to work under taint.

The user has some options though. He can abandon the attempts to install it. He can install whatever is in his private installation in the standard directories. He can recompile perl to have his PERL5LIB part of the default @INC - perhaps by creating a private perl installation. He can make sure the directories of his PERL5LIB are put as -I arguments when the test scripts are called. He can modify the test scripts to include the relevant directories in @INC. He can modify the test scripts and remove the -T or -t options.

It's a delicate issue. Should you, or shouldn't you run tests with taint enabled? Not because the environment is untrusted, but because the purpose of tests is to show the module works correctly. And that would include running correctly with taint enabled.

Perl --((8:>*