Oops. Thanks for pointing that out. (I should have tested before posting.)

While we're at it (now that I have tried it out), there's another aspect of my snippet that didn't work as I expected: re-opening STDOUT that way does not seem to put things back the way they were:

#!/usr/bin/perl

warn "\n==normal case:\n";
print "running ls:\n";
system( "ls" );

close STDOUT;

warn "\n==STDOUT closed:\n";
print "running ls a 2nd time\n";
system( "ls" );

open STDOUT, '>-';

warn "\n==STDOUT reopened:\n";
print "running ls a 3rd time\n";
system( "ls" );
[download]

When I run that in at terminal shell, the only output I get on STDOUT comes from the "normal case", nothing shows up after the second and third "warn" messages (bummer).

I had to read farther into the manual description of open to get it right:

#!/usr/bin/perl

warn "\n==normal case:\n";
print "running ls:\n";
system( "ls" );

open my $oldout, ">&STDOUT";  # "dup" the stdout filehandle
close STDOUT;

warn "\n==STDOUT closed:\n";
print "running ls a 2nd time\n";
system( "ls" );

open STDOUT, '>&', $oldout;  # restore the dup'ed filehandle to STDOUT

warn "\n==STDOUT reopened:\n";
print "running ls a 3rd time\n";
system( "ls" );
[download]

(updated to add comments)

That sort of thing could make a big difference in the OP's situation, where there might be other stuff to be written back to a browser after running a system call.