Would u happen to have a small example of saving, redirecting STDOUT to a file, and restoring STDOUT back? Thanks.

Literally copied from the link I provided above:

#!/usr/bin/perl
open(my $oldout, ">&STDOUT") or die "Can't dup STDOUT: $!";
open(OLDERR, ">&", \*STDERR) or die "Can't dup STDERR: $!";
open(STDOUT, '>', "foo.out") or die "Can't redirect STDOUT: $!";
open(STDERR, ">&STDOUT") or die "Can't dup STDOUT: $!";
select STDERR; $| = 1; # make unbuffered
select STDOUT; $| = 1; # make unbuffered
print STDOUT "stdout 1\n"; # this works for
print STDERR "stderr 1\n"; # subprocesses too
open(STDOUT, ">&", $oldout) or die "Can't dup \$oldout: $!";
open(STDERR, ">&OLDERR") or die "Can't dup OLDERR: $!";
print STDOUT "stdout 2\n";
print STDERR "stderr 2\n";
[download]

I think that, if I were doing this, I would want to do it very explicitly, to avoid side-effects.   In other words, I would design my app in such a way that there is a universally-available (to the app...) object which has a method to generate output.   The entire application uses that method.   Unbeknownst to it, that method writes the output by some means to a temporary file.   Then, when the app is ready to deliver that output to the end-user, a final bit of code slurps that file and pumps it to STDOUT.

What I am very-deliberately doing in this case is trying to build in flexibility and “future-proofing.”   There is probably not one thing that is more pervasive, in any application built for any environment and for any purpose, than “how that application generates and delivers its output.” Therefore, if when changes occur down the line, a change to this aspect of the system would be “a highly pervasive (HIPER) change,” as IBM used to say.   Nothing is more de-stabilizing, both to the app and to your receding hairline and what’s left of your social life, than, “a HIPER change to a deployed production system.”   Do everything that you reasonably can to prepare for it, as early as you can in the design-and-build process.