Your problem is that the tool is sending errors out on STDERR while you read STDOUT. If you want to trap the error you will need to trap both filehandles.

This sounds like the kind of thing that I have used IPC::Open3 for in the past. Now be aware that doing this is somewhat tricky. As soon as you use that module you need to figure out how to handle STDIN, STDOUT, and STDERR. Just to make life fun, if are trying to read on one of the pipes while it tries to write on another, you may be waiting for a good while. Also you need to think about the fact that when the poor child dies you need to reap it with wait or waitpid.

This definitely deserves a generic "run_system" command. And since all errors will be coming from there, you want to use Carp and confess to any problems.

Therefore I recommend looking for ways to not have to do that work yourself. (Push it off to the OS. After all that is why you have one!) Personally I would use File::Spec to pick up the devnull function to get null data for STDIN. I would use File::Temp to create a tempfile for STDERR (which you can seek on then read at your leisure), and I would read STDOUT yourself.

Then your pattern looks like this:

1. Get the system command.
2. Open the handles it needs.
3. open3.
4. read STDOUT.
5. Do a wait or waitpid to collect the zombie.
6. Check $? and read what was printed to STDERR. Handle the error if there was one.
7. Return what came from STDOUT.

In case it isn't obvious, I have written this kind of thing in the past. IIRC it wasn't portable (worked on Linux, but not under Windows, never bothered to find out why) so consider yourself warned that I have never bothered to do this portably. But doing it, even non-portably, was quite instructive...