#!/usr/bin/perl
use warnings;
use strict;

print STDERR "STDERR is on.\n";
my ($stderr_fh, $err_msg_ref) = suppress_std_err();
print "STDERR is now off and error messages are being suppressed and s
+aved.\n";
print STDERR "I'm an error message.\n";
restore_std_err($stderr_fh);
print STDERR "STDERR is back on\n";
print "Errors reported while STDERR was off: $$err_msg_ref\n";

#Saves STDERR in filehandle then turns it off.
#Any error messages that occur while STDERR is off are stored for safe
+keeping.
sub suppress_std_err {
        my $suppressed_std_error_messages;
        open (my $saved_std_err_fh, ">&", STDERR);
        close STDERR;
        open (STDERR, ">", \$suppressed_std_error_messages);
        return ($saved_std_err_fh, \$suppressed_std_error_messages);
}

#Restores STDERR from saved filehandle.
sub restore_std_err {
        my $old_std_err_fh = shift;
        close STDERR;
        open (STDERR, ">&", $old_std_err_fh);
}
[download]

Yeah, but why?

Redirecting STDERR is a tricky thing, there are long perldocs on this issue, and I'm not too confident about portability here.

And you loose the ability to just selectively silence known warnings, while still being alarmed by unknown issues. So you will need to parse that variable afterwards.

If you really want to capture all errors indiscriminately, better use warnings FATAL => 'all' inside eval (hence only for that lexical scope)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

UPDATE

well, ok. One advantage of redirecting STDERR is that print STDERR will also be caught.

But the errors you've shown most certainly come from some Carp routines.

(FWIW you might alsow want to look into Carp for silencing advice)