confim

problem ocuurs on bash and zsh with Terminal and ITerm2, so i guess it must be jruby's Readline jar

jruby 1.7.6 (1.9.3p392) 2013-10-22 6004147 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_45-b18 [darwin-x86_64]
OS X 10.9 Mavericks

As long as it's broken you can disable long output paging (which is using less) by calling

Pry.config.pager = false

On a rails porject you can just put this code in an initializer

issue fixed by: pry/pry#992

I would prefer that issues are not closed just because a library or app works around them. There's a good chance this behavior is still broken in JRuby but we'd never know it because the issues get closed.

Was anyone ever able to narrow this down to a simple case in JRuby? There were a lot of IO-related changes in 1.7.5, but we don't want to regress on behavior.

Still appears to be an issue on jruby-1_7 as of today.

...
 53,
 54,
 55,
 56,

<page break> --- Press enter to continue ( q<enter> to break ) --- <page break>
q^M

A backtrace of this shows that it's waiting for input, and that it's using the non-selectable ReadableChannel stuff. That may be the source of the regression, but I'll fix it and see.

It just occurred to me that there's something very odd going on for carriage returns to be showing up as ^M in the console. I think this is more than simply an IO issue; it's like the terminal has been reconfigured in some way.

A trivial example at the command line works fine; something's causing gets to go wacky.

$ jruby -e "loop { puts 'hello'; break if \$stdin.gets.chomp == 'q' }"
hello

hello

hello
q

$

Yeah, there's something really strange going on. I added logging to our lower-level IO stuff, and it shows that for some reason the enter key is sending \13 instead of \10 when running under pry.

At command line without pry:

system ~/projects/jruby-1.7 $ jruby -e "gets"
going into gets fast with delim = 10
asdf
byte at 0 is 97
byte at 1 is 115
byte at 2 is 100
byte at 3 is 102
byte at 4 is 10
read: 5
10

Under pry:

[1] pry(main)> gets
going into gets fast with delim = 10
^Mbyte at 0 is 13
^Mbyte at 0 is 13
^Mbyte at 0 is 13
^Mbyte at 0 is 13
^Mbyte at 0 is 13
^Mbyte at 0 is 13

byte at 0 is 10
read: 7
10
=> "\r\r\r\r\r\r\n"
[2] pry(main)> quit

The \10 that eventually gets sent is from me doing Ctrl-j.

There's a possibility this is a bug in how we handle mapping newline characters.

Ok, this looks like a regression in the readline library we use. I have narrowed down this behavior to the call to readline that occurs in Pry.readline (pry_instance.rb). Before that call, "enter" produces \10 characters. After the call, it produces \13 characters. This causes calls to gets to not see the default line terminator and exhibit the behavior reported in this bug. I'm not sure what's wrong with our readline library (jline) that would cause this.

@headius ah, nice, thanks for getting to the bottom of it. hm okay, sounds tricky to solve?

@headius how does rb-readline behave on jruby? could using that instead be a viable workaround?

rb-readline might be an option, but it uses a lot of low-level APIs...some of which we can only simulate atop the JVM.

@headius thanks. with that in mind, I think we won't do that then.

Was this reported to jline? Any link to issue?
Is there any plan to resolve this? I only got it in pry and glad they worked around it, but would be nice to get to the bottom of it.

I've just had the same issue with JRuby 1.7.19, so I guess the underlying issue hasn't been fixed yet.
ruby -v gives me the following output:
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on OpenJDK 64-Bit Server VM 1.6.0_34-b34 +jit [linux-amd64]

I am abandoning fixing this for 1.7.x but it is still present for 9.x. I am guessing it is still our library dependency not doing something we expect.

Let's go with the more recent bug for ^C not working in IRB anymore: #3721.