Net::HTTP Closes STDIN

[Eric Hodel]

Bingo. It's actually a pretty significant problem for HighLine
because after you do something like fetching a web page, HighLine
believes $stdin to e closed and won't allow you to ask the user any
more questions. I fear we will need to disable HighLine's eof?()
check the work around this.

Then it sounds like HighLine needs to check #closed? or continue
reading until IOError. If #eof? returns true you've read everything
you could up to now. Nothing prevents more data from appearing on
the socket after you've checked for #eof?.

 

[James Edward Gray II]

Then it sounds like HighLine needs to check #closed? or continue
reading until IOError.

But, as you pointed out, closed?() is not the same as eof?().

Watching for an IOError also isn't very reliable since HighLine's
input stream may be anything from STDIN, to a Socket, with IO and
StringIO in between.

For now, I've added a workaround so user code can disable HighLine's
EOF checks as needed.

Thank to all for helping me to understand this issue.

James Edward Gray II

 

[ara.t.howard]

Thank to all for helping me to understand this issue.

great - that make one of us! ;-)

-a

 

[gwtmp01]

great - that make one of us! ;-)

I spent a bit of time looking at the code in io.c. This
file has changed radically from the 1.8 branch to the
1.9 (trunk) branch. But...

On my platform (Darwin 8.8.0 Power Macintosh):
1.9 from sources works
1.8 (head) from source works
1.8.5 from darwin ports broken
1.8.3 from source works

So perhaps there is something to Ara's suggestion that
the packaged version of ruby for Mac OS X is broken. I
don't have access to linux.

I'm rebuilding 1.8.5 from source now...


Gary Wright

 

[gwtmp01]

I'm rebuilding 1.8.5 from source now...

Is the Darwin Ports (macports) maintainer for Ruby on this list?

The problem that James originally reported only seems
to exist in the Darwin Ports version of 1.8.5:

$ ruby -v
ruby 1.8.5 (2006-08-25) [powerpc-darwin8.7.0]

I just built from the current 1.8.5 branch and the problem doesn't
exist:

$ ./ruby -v
ruby 1.8.5 (2007-01-27 patchlevel 17) [powerpc-darwin8.8.0]

$ ./ruby -e 'Thread.new{} and p $stdin.eof?' # pause until ctrl-D
entered
true

Gary Wright

 

[James Edward Gray II]

The problem that James originally reported only seems
to exist in the Darwin Ports version of 1.8.5:

Na. I don't use MacPorts. I built Ruby from source.

James Edward Gray II

 

[James Edward Gray II]

I just built from the current 1.8.5 branch and the problem doesn't
exist:

$ ./ruby -v
ruby 1.8.5 (2007-01-27 patchlevel 17) [powerpc-darwin8.8.0]

I wonder if this is related to the --enable-pthread option. I used
it and wouldn't be surprised to hear that MacPorts did too. Did you
use this option when you did this test?

James Edward Gray II

 

[gwtmp01]

I just built from the current 1.8.5 branch and the problem doesn't
exist:

$ ./ruby -v
ruby 1.8.5 (2007-01-27 patchlevel 17) [powerpc-darwin8.8.0]

I wonder if this is related to the --enable-pthread option. I used
it and wouldn't be surprised to hear that MacPorts did too. Did
you use this option when you did this test?

I just typed:

autoconf; ./configure; make

I'll try:

/configure --enable-pthread; make

and report back...

Gary Wright

 

[gwtmp01]

I wonder if this is related to the --enable-pthread option. I used
it and wouldn't be surprised to hear that MacPorts did too. Did
you use this option when you did this test?

Sure enough. When I compiled 1.8.5 with --enable-pthread the test
failed.

Ruby 1.9 wouldn't compile with --enable-pthread but works without.


Gary Wright

 

[James Edward Gray II]

Sure enough. When I compiled 1.8.5 with --enable-pthread the test
failed.

Ah, so it's likely a pthread issue. Most of the instruction articles
floating around the web for installing Ruby on Mac OS X recommend
adding that option, which is probably why we see this on that platform.

What is the advantage of pthread? I don't know.

James Edward Gray II