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 );
}