gets returns nil very early in the process lifetime.

This could be highly system-dependent.

$ uname -v
Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64
$ bash -c '(sleep 0; echo "Hello") | jruby -v -e "puts gets"'
jruby 1.7.0.RC2 (1.9.3p203) 2012-10-15 f54452f on Java HotSpot(TM) 64-Bit Server VM 1.7.0_07-b10 [darwin-x86_64]
Hello

I am a little suspicious, since "puts" should never print out "nil" for a nil value (it prints an empty line). Seems like the code given isn't the code you actually ran to see a "nil" printed.

gets should block unless the stream is closed, so I wonder if perhaps the input pipe is getting shut down before it has a chance to read.

I have examined a bit further.
First the OS:

$ uname -a
Linux hermes 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Further: I can only reproduce this with jruby 1.6.8 (not 1.7.0-RC2). Even on Jruby 1.6.8 I can only reproduce this with jruby aliased to bundle exec jruby. Trying without bundle exec I cannot reproduce it.

Anyway under these conditions, I can tell you for sure that gets returns a nil value:

$ echo "Hello" | bundle exec jruby -v -e "puts gets.class"
jruby 1.6.8 (ruby-1.8.7-p357) (2012-09-18 1772b40) (OpenJDK 64-Bit Server VM 1.7.0_07) [linux-amd64-java]
NilClass

Further letting puts print out a nil value does print out nil on jruby 1.6.8 (even without bundler), Not 1.7.0-RC2 though.

$ jruby -v -e "puts nil"
jruby 1.6.8 (ruby-1.8.7-p357) (2012-09-18 1772b40) (OpenJDK 64-Bit Server VM 1.6.0_24) [linux-amd64-java]
nil

This may very well be another bug... But only in 1.6.8, so its not worth reporting

So I close this bug because it is unreproducible on jruby 1.7.0, and it also seems to be a bundler problem.

Thanks for looking into this and challenging me on the conditions under which it occurs.

Can someone close this as fixed in 1.7.0-RC2

Resolving, as requested.

$ echo "hello" | bundle exec jruby -v --1.9 -e 'puts gets'
jruby 1.6.8 (ruby-1.9.2-p312) (2012-09-18 1772b40) (Java HotSpot(TM) 64-Bit Server VM 1.7.0_07) [darwin-x86_64-java]
hello

$ jruby -v -e 'puts nil'                
jruby 1.6.8 (ruby-1.8.7-p357) (2012-09-18 1772b40) (Java HotSpot(TM) 64-Bit Server VM 1.7.0_07) [darwin-x86_64-java]
nil
$ jruby -v --1.9 -e 'puts nil'                
jruby 1.6.8 (ruby-1.9.2-p312) (2012-09-18 1772b40) (Java HotSpot(TM) 64-Bit Server VM 1.7.0_07) [darwin-x86_64-java]

This is resolved as fixed, and I suspect the actual problem was that our faking of "exec" in 1.6- is probably to blame. Our exec in those earlier versions of JRuby would spin up a new JRuby instance within the same runtime and attempt to run it as though it were a new process. This very likely caused IO and buffering effects you'd see when piping to "bundle exec" and friends. With JRuby 1.7+, exec will actually exec, inherit stdio streams, and apparently not exhibit this issue.

Thanks for the report! We do fall back on the non-native exec in some cases, so it's good to have this on the books.