From: "Mark J. Reed" <markjreed@...>
Date: 2003-09-19T01:35:01+09:00
Subject: Re: closing stderr

On Fri, Sep 19, 2003 at 12:49:43AM +0900, Michael Garriss wrote:
> I would like to prevent some output that is going to stderr during a 
> call to a third party lib just during that call.  My first guess was:
> 
> STDERR.close_write
> ThirdPartyLib::call_some_annoying_function
> STDERR.????

If the third-party library is a Ruby library and is well-behaved,
then you don't have to mess with STDERR; just change $stderr to
point to someplace else.

Remember: the global variable $stderr is where Ruby actually sends
standard error output.  The constant STDERR is just a saved
copy of the value $stderr got when Ruby started up.

So something like this should do the trick:

begin
    $stderr = File.open('/dev/null', 'w')
    ThirdPartyLib::call_some_annoying_function
ensure
    $stderr = STDERR
end

If, on the other hand, the third-party library is not so well-behavied
and messes with STDERR directly, then you can close it.  But you need to save
a copy of it first and restore it later.

begin
    errCopy = ($stderr = STDERR).dup
    STDERR.close
    ThirdPartyLib::call_some_annoying_function
ensure
    $stderr = errCopy	
    STDERR = $stderr
end

Note that you have to assign something open to $stderr before assigning
to STDERR, or else the assignment to STDERR throws an exception trying to
print the "already initialized constant" warning and the assignment
doesn't complete.  There is probably a cleaner way of doing this.
    
Question on the subject of well-behaved libraries: if you invoke
native code from Ruby, is that run with file descriptor 2 initially
matching $stderr?  

-Mark