You can redirect it to a file or variable ( redirecting STDERR ) or capture it and deal with it later ( capturing STDERR - i personally like Capture::Tiny for this... ). Loads of examples out there! HTH.

close(STDERR);
open(STDERR, '>', \my $BUF) or die $!;

warn "hey there";
$BUF=~/hey there/ or die;
[download]

Yes! You rawk, thank you.

I'm not sure I understand the your question.

Are you wanting to be able, from within your code, to see what has been output to STDERR?

If so, then the reply from kennethk is an excellent place to start.

My only caution is that if you map SDTERR to a variable and then have several places where output might go to STDERR, then each successive write to STDERR will overwrite the variable. So you'll need to check it after every possible STDERR write.

Alternativly, you could consider trapping the error using an eval() construct where you can write your own simple error handler that would perhaps output successive messages to an array which you can then check at your leizure.

On the other hand, if you simply want to see when or if an error message is being written properly, then there are other possibilities.

For instance, if you're running from the Command Line then STDERR is automatically mapped to STDOUT and the messages are written to the console. The only challenge, at least for me, is that there is no particular distinguishing markings that tell you whether STDERR or STDOUT is being written. In that instance, I usually pre-pend something like 'STDERR:' to the message (in the OP's case it would be, for example, 'STDERR: miscellaneous') so that I can easily pick out the STDOUT from the STDERR messages.