<html>
<body>
At 01:31 PM 6/29/2005, Jeremy Leader wrote:<br>
<blockquote type=cite class=cite cite="">But it's gzip's STDOUT which is
piped to FILE, it doesn't<br>
affect the script's STDOUT, which is what CGI pipes back<br>
to the client.</blockquote><br>
The CGI script runs as a single process id, and only has<br>
one STDOUT identifier in the /dev directory.<br><br>
I read about this in an ORA perl book.<br>
Mainly as 10 years ago I tried and tried and tried,<br>
and never got it to work, and wondered why, so I<br>
went looking.<br><br>
I could not quickly google an online reference. This came
close:<br><br>
<a href="http://www.cs.usask.ca/resources/documentation/perl/perlfaq8.html" eudora="autourl">http://www.cs.usask.ca/resources/documentation/perl/perlfaq8.html</a><br><br>
<b><a name="perlfaq8_stdin_0"></a>STDIN, STDOUT and STDERR are shared
<br>
</b>Both the main process and the backgrounded one (the ``child''
process) share the same STDIN, STDOUT and STDERR filehandles. If both try
to access them at once, strange things can happen. You may want to close
or reopen these for the child. ...snip...<br><br>
--<br><br>
But for CGI once you reopen the STDOUT, the parent can no longer
pass<br>
back data to the web server to give a web page to the surfer.<br><br>
<br><br>
</body>
</html>