I would agree with the first reply, that it would be prudent to store stderr and stdout to separate output files.

Apart from that, you want to use a system call instead of backticks, because that way, any STDOUT content from the sub-shell will go to your script's STDOUT, and likewise for STDERR. Consider the following demonstration:

#!/usr/bin/env perl

use strict;
use warnings;

open( STDOUT, '>>', '/tmp/foo.log' );
open( STDERR, '>>', '/tmp/foo.err' );

my $testfile = "/tmp/test.$$.txt";

   # this should create a test file and produce no other output:
my $failure = system( "echo this is a test > $testfile" );

   # this adds a message to foo.err:
if ( $failure ) {
    warn "Failed to create/rewrite $testfile\n";
} else {
    warn "$testfile was successfully created/rewritten\n";
}

   # this adds a message to foo.log:
printf "size of $testfile is %d bytes\n", -s $testfile;

   # this adds the content of the test file to foo.log:
system( "cat $testfile" );

   # this adds an error message to foo.err:
system( "cat /tmp/no.such.file" );

   # the next two systems calls produce no output at all
   # (because the output is being redirected to /dev/null): 
system( "cat $testfile > /dev/null" );
system( "cat /tmp/no.such.file 2> /dev/null" );

   # the next system call will append data to $testfile,
   # AND append the same data to "foo.log":
system( "echo yet another test | tee -a $testfile" );
[download]

The point about the last three system calls is to show how you can control what does and doesn't reach your script's STDOUT and STDERR.