--005045029585b26ebf04778fca25
Content-Type: text/plain; charset=ISO-8859-1

>
> 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.
>>
>
> Oh, that wasn't clear to me from your posting.  I thought you were
> referring to the receiver being a StringIO object.  Actually, when rereading
> your original posting both interpretations seem valid...


Yes, I did not think of the other interpretation at first.

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

Well, _now_ I know. :-)


Hehe... I did not specify my problem well enough.   ;)


>
> So you are trying to catch output of Ruby code run within the same process
> and of which you are not sure that it actually always references $stderr
> during write operations.  You suspect it might store $stderr in some local
> variable and thus be unaffected by your change to the global variable.
>
> I'd say the risk is rather low since it does not really make sense to
> replace $stderr with something else (unless someone is a lazy typer).
>

Maybe I am the only one who does this, but I habitually use STDERR
instead of $stderr.


> The problem remains the same: StringIO and IO / File are two different
> things and I believe there is no reasonable way to add functionality to them
> that they can mutate.
>
> The safest seems indeed to redirect the IO to a pipe, have a background
> thread read from the pipe and store data in a String or StringIO and then
> execute the code whose output you want to catch.  As a nice side effect that
> would also work for subprocesses.
>
>
Thanks for discussion!

Hal


>
> Kind regards
>
>        robert
>
> --
> remember.guy do |as, often| as.you_can - without end
> http://blog.rubybestpractices.com/
>
>

--005045029585b26ebf04778fca25--