Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Redirect STDOUT in CGI App

by rpike (Scribe)
on Jul 28, 2011 at 15:24 UTC ( #917284=perlquestion: print w/replies, xml ) Need Help??
rpike has asked for the wisdom of the Perl Monks concerning the following question:

What's the easiest/best/most efficient way to redirect all STDOUT content to a file and then, afterwards, send that content to the normal STDOUT (i.e. response to client)? Thanks in advance for any helpful advice.

Replies are listed 'Best First'.
Re: Redirect STDOUT in CGI App
by kennethk (Abbot) on Jul 28, 2011 at 15:30 UTC
    The easiest way is to do it is in the shell. However, if you are looking to wrap an existing CGI script to check/filter its output before forwarding it on entirely in Perl, I would clone STDOUT and then redirect the original into a scalar for whatever inspection was appropriate/necessary. Cloning and redirecting is discussed in good detail in open.
      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";
Re: Redirect STDOUT in CGI App
by sundialsvc4 (Abbot) on Jul 29, 2011 at 12:59 UTC

    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://917284]
Approved by kennethk
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (9)
As of 2017-04-23 18:23 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (431 votes). Check out past polls.