Net::HTTP Closes STDIN

On Jan 30, 2007, at 19:08, James Edward G. II wrote:

On Jan 30, 2007, at 5:28 PM, [email protected] wrote:

this could get tricky to debug!

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?.

On Thu, 1 Feb 2007, James Edward G. II wrote:

Thank to all for helping me to understand this issue.

great - that make one of us! :wink:

-a

On Jan 31, 2007, at 12:30 AM, Eric H. wrote:

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 G. II

On Jan 31, 2007, at 7:05 PM, [email protected] wrote:

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 W.

On Jan 31, 2007, at 2:32 PM, [email protected] wrote:

On Thu, 1 Feb 2007, James Edward G. II wrote:

Thank to all for helping me to understand this issue.

great - that make one of us! :wink:

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 W.

On Feb 1, 2007, at 2:35 PM, [email protected] wrote:

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 G. II

On Feb 1, 2007, at 2:35 PM, [email protected] wrote:

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 G. II

On Feb 1, 2007, at 3:46 PM, James Edward G. II wrote:

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 W.

On Feb 1, 2007, at 3:46 PM, James Edward G. II wrote:

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 W.

On Feb 1, 2007, at 5:51 PM, [email protected] wrote:

On Feb 1, 2007, at 3:46 PM, James Edward G. II wrote:

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.

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 G. II