From: Hal Fulton <rubyhacker@...>
Date: 2009-11-04T08:26:03+09:00
Subject: Re: StringIO and reopen

--001636c92b01a2a5c504777fcf91
Content-Type: text/plain; charset=ISO-8859-1

>
>
>  This will be difficult to do because then StringIO would somehow have
>>> to change its type.  Of course you could achieve that with some kind
>>> of proxy pattern but I doubt that this would be a good idea; we all
>>> would always pay the price of the overhead (1 more object per IO /
>>> StringIO) for a feature which seems rarely wanted (I cannot recall
>>> having seen a request like this in years).
>>>
>>
>  Well, reopen also can take a string, I believe. So it already takes
>> more than one type. But the overhead argument is valid.
>>
>
> The string is interpreted as a file name.  With changing type I meant that
> a StringIO after #reopen (either with number, IO object or string as file
> name) must behave like an IO or File object which is a different type.  I
> was not talking about the argument types to method #reopen but the type of
> the object itself.
>
>
Yes - but what I meant was, reopen already checks its argument and
behaves differently based on what is passed in, so it *could* of course
check for a StringIO as well.


[snip]

Yes, this obviously works, but it is irrelevant to what I am trying
to do.


>  How would I, for example, capture all that went to standard error
>> in a StringIO object?
>>
>
> You can try to do
>
> $stderr = StringIO.new
>
> but this works only within the same process, i.e. not for sub processes.
>  There is no way I am aware of to redirect a file descriptor to an in memory
> structure.  If you want the redirection to work for a child process and get
> the data in the parent you need to use one of the popen family of methods.


I am not interested in subprocesses actually.

The problem with what you do here is that it changes the variable $stderr
to a different object (leaving the original object of course unaffected).

So it depends, I think, on code referencing $stderr rather than STDERR. (The
code whose stderr I am catching is not necessarily my own.)

Maybe I could also do const_set(STDERR, my_io) before any requires.  That is

something I have not tried.

Another ugly trick, of course, would be something like doing a popen, a
reopen,
then read from the pipe periodically. Or perhaps even redirect stderr to a
file
and do a File::Tail on that...

Ah, well. It is not something that will come up often.


Hal

--001636c92b01a2a5c504777fcf91--