From: Tanner Burson <tanner.burson@...>
Date: 2005-10-25T05:41:39+09:00
Subject: Re: $stderr.reopen bug?

------=_Part_46655_17788981.1130186496955
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/24/05, Daniel Berger <Daniel.Berger@qwest.com> wrote:
>
> Tanner Burson wrote:
> > Hi,
> > I'm working through what seems like it should be a simple operation,
> > re-routing STDERR to point elsewhere. I can do the following
> >
> > $stderr.reopen("/dev/null")
> >
> > which works fine. But what I'd like to do is capture that output, so I
> > figured StringIO would be the way to go. According to the docs for
> IO#reopen
> > it can take an IO object as it's only parameter, and use that to
> re-open,
> > but when I do the following
> >
> > require 'stringio'
> > str_io =3D StringIO.new
> > $stderr.reopen(str_io)
> >
> > I get
> >
> > TypeError: can't convert StringIO into String
> >
> > any ideas? Is the documentation just wrong, and it can only take a
> string
> > arg? Or will it take only a File IO object?
>
> You'll need an IO object because, behind the scenes, IO.reopen grabs the
> fileno
> from the object and uses the dup2() function (at least, on *nix).
>
> The StringIO#fileno method exists, but returns nil, since there is no
> associated fileno with a StringIO object. Actually, I don't even think it
> gets
> that far. I suspect it's choking on the rb_io_get_io() internal function.


I think its passing rb_io_get_io() clean, but returning that StringIO isn't
a "true" enough IO object, so it trys to treat the StringIO parameter as a
filename to reopen with. I was hoping there was a way around this.

Whether or not this could be made to work with StringIO, I'm not sure.


Well thanks anyway :) Good to know it wasn't something I was doing anyway.

Regards,
>
> Dan
>
>


--
=3D=3D=3DTanner Burson=3D=3D=3D
tanner.burson@gmail.com
http://tannerburson.com <---Might even work one day...

------=_Part_46655_17788981.1130186496955--