pry overwrites my console history with its own

[dam13n]

is there a setting or way to deal with this? really kills efficiency

[kyrylo]

Any details about your environment?

[dam13n]

Sure, but what details are you looking for? Latest OSX, Ruby, and Rails.

Problem occurs when I am in rails console testing sections of code with binding.pry. The pry history is kept, but overrides my non-pry console activity.

[theworkerant]

Same for me. :+1:

[agrberg]

Both Pry and IRB write their histories to Readline::HISTORY. When you enter pry you have all your IRB history in Readline::HISTORY and then pry loads its history on top of that. When you exit Pry this isn't changed so you end up back in IRB with all of Pry's history and thus when you exit IRB it writes Pry's history to IRB's history file.

[kyrylo]

Are there any repro cases? I cannot seem to reproduce this issue:

[agrberg]

I can reproduce it when I access Pry from within IRB. I believe this is the same as when pry is access from the Rails console or server via binding.pry.

[kyrylo]

Thanks, I can reproduce it now.

I am wondering, though, how common is this? It seems to be a highly unlikely scenario when you launch IRB and then Pry within IRB. It seems like the original post by @dam13n is talking about some other scenario.

If this is the only case where this issue can be seen, then it seems to be insignificant.

[agrberg]

From his 2nd post it seems like he's experiencing the same case I am where rails console and rails server use IRB by default but will start pry within them when using binding.pry to debug something.

I can't speak to how common it is in the wild as our cases are Rails specific. However, it does effect all Rails developers who do not or, for whatever reason (team, setup, environment, etc.) cannot, use Pry instead of IRB. I've learned to live with but got close to the issue in #1560. Pry is a tool I estimate I'll always use so it would be great if there was an option or setting to help with this but I can't say it's a higher priority than other ongoing work in Pry.

[ddoherty03]

I wanted to copy my comment from the closed issue, so here it is. The problem arises in debugging with binding.pry _any app that uses readline_.

My use case is that I have an app that uses readline. When I debug it by inserting a binding.pry in the code, pry clobbers my app's Readline::HISTORY. So this fix should not assume that it is a problem with just IRB history. So the methods might be better named prior_history..., etc, rather than irb_history...

[kyrylo]

Thanks, I understand now.

I've investigated this a little bit and it seems like there's no good solution to this because the history object provided by the Readline library is global and initialised only once:

https://github.com/ruby/ruby/blob/bf508be28b6a5528c8e61d5bc7333a94948c053d/ext/readline/readline.c#L2003

We will probably have to do something like https://github.com/pry/pry/pull/1560 anyway. That doesn't sound very optimistic, though, since it'd be a hack.

An alternative approach would be using Pry without readline :) I currently don't have any better ideas. By the way, I haven't tested it, but it seems like if you go the other way around, IRB would be the one to blame. If you run Pry and require IRB, then run binding.irb, you'd have the same problem because IRB doesn't handle this issue either.

[kyrylo]

My initial plan was to include the fix for this into v0.12.0 but after thinking more about it I don't want to write a half-baked solution. The truth is that I don't know the proper solution for this problem. I am not closing this because it is a problem but don't expect a fix any time soon unless there's some break through in Readline.