perlop, qx// operator :

> To read both a command's STDOUT and its STDERR separately, it's
> easiest and safest to redirect them separately to files, and
> then read from those files when the program is done:
> 
> system("program args 1>/tmp/program.stdout 2>/tmp/program.stderr");

So, if I was you I wasn't relying on the fact that B doesn't produce
anything to STDOUT and trying to redirect it's STDERR there - you're
locking yourself in the cage by this .. What if this will change ?
The good thing, IMHO, will be to write a little subroutine getting a
command to launch and returning it's STDERR and STDOUT separately in two
variables. Oh, I did it once, here we go :

# launches the script and returns it's STDOUT and STDERR separately
sub launch {
        local ( $_, $/, *FIN );
        my ( $script ) = @_;
        
        # redirecting both STDOUT and STDERR to the corresponding files and reading 
them later

        my $stdout_file = "$script.stdout";
        my $stderr_file = "$script.stderr";
        
        system "$script 1>$stdout_file 2>$stderr_file" # NOTE THE DOS SYNTAX !!!
                and warn "Failed to launch [$script] ! \a\n";
                
        # Even if we failed to launch the script - it's STDOUT and STDERR are still 
taken
        open( FIN, "$stdout_file" ) or die "Unable to open [$stdout_file] for reading 
: $! \a\n";
        my $stdout = <FIN>;
        close( FIN ) or warn "Unable to close [$stdout_file] : $! \a\n";               
 
        unlink $stdout_file;

        open( FIN, "$stderr_file" ) or die "Unable to open [$stderr_file] for reading 
: $! \a\n";
        my $stderr = <FIN>;
        close( FIN ) or warn "Unable to close [$stderr_file] : $! \a\n";               
 
        unlink $stderr_file;
        
        ( $stdout, $stderr );
}


Reply via email to