Pry: Keep pry history separate from rails console history

[krukgit]

I'm using pry in my Rails 4.1 projects and every time I enter pry when within the console, it loads pry history on top of the console history, so even if I quit pry straightaway, my history is overwritten with the commands I run hours before in a different pry session. Is there a way to change this behaviour without disabling pry history?

Example:

2.1.1 :002 > puts 'test'
test
 => nil 
2.1.1 :003 > MyClass.last.my_method
...
[1] pry(#<MyClass>)> quit
2.1.1 :004 > <now history is all messed up>

[rf-]

Wow, I'm surprised this has never come up before. I think it should be easy to fix by checking if Readline::HISTORY has anything in it before we populate it.

On Wed, Jul 16, 2014 at 3:01 AM, Maciej Kruk [email protected]
wrote:

I'm using pry in my Rails 4.1 projects and every time I enter pry when within the console, it loads pry history on top of the console history, so even if I quit pry straightaway, my history is overwritten with the commands I run hours before in a different pry session. Is there a way to change this behaviour without disabling pry history?
Example:

2.1.1 :002 > puts 'test'
test
 => nil 
2.1.1 :003 > MyClass.last.my_method
...
[1] pry(#<MyClass>)> quit
2.1.1 :004 > <now history is all messed up>

---

Reply to this email directly or view it on GitHub:
https://github.com/pry/pry/issues/1266

[2called-chaos]

I've got a similar problem (or actually the same + a few more). The general problem is that pry doesn't revert the state of Readline as it was before. I'm writing a console script which is using readline and as soon as I invoked pry once, Readline is messed.

I fixed the history for the moment but it also applies to completion procs, etc. Imho all changes to readline should be reverted on the end of a pry session...

def _tc_pry args, str
  _hist_was = Readline::HISTORY.to_a
  Readline::HISTORY.pop until Readline::HISTORY.empty?

  # type "exit" or "help" or start prying!
  binding.pry
ensure
  Readline::HISTORY.pop until Readline::HISTORY.empty?
  _hist_was.each{|s| Readline::HISTORY << s }
end

(from https://github.com/2called-chaos/mcl/blob/dev/lib/mcl/console_client/terminal/commands.rb#L5)

[rusterholz]

+1.

This is one of the most obnoxious issues with any development tool I've ever tried (and I've been developing since the TRS-80 came out, if that gives you a sense of how much I mean this).

In practice, this issue means I _avoid_ using Pry as much as possible, because it mutilates the console history which often has something I need in it.

[rusterholz]

Any updates on this?

[dam13n]

Yea, agreed @rusterholz . It's super annoying and would be awesome if there were some options here.

[ozydingo]

Modified from 2called-chaos's response, this is my workaround that allows you to call binding.hpry (or any Object#hpry) that will (a) not clobber your console history, and (b) function otherwise identically to binding.pry, without the extra step of the pry starting you off inside the _tc_pry method. Obviously caution, as we're opening up Object here, but so does the pry gem so I don't feel that bad about it.

class Object
  def hpry(*args)
    save_hist = Readline::HISTORY.to_a
    self.pry(*args)
  ensure
    Readline::HISTORY.clear
    save_hist.each{|line| Readline::HISTORY << line}
  end
end

[ddoherty03]

I vote this issue up. Am developing an app with a console shell and when I debug with pry, the app's history is replaced with pry's history after pry quits.

[rusterholz]

This is still easily reproduced with ruby 2.3.1 and pry 0.10.4:

Cedar:blinker rusterholz$ irb
2.3.1 :001 > require 'pry'
 => true
2.3.1 :002 > puts 'one'
one
 => nil
2.3.1 :003 > puts 'two'
two
 => nil
2.3.1 :004 > binding.pry

Frame number: 0/12
[1] pry(main)> puts 'three'
three
=> nil
[2] pry(main)> exit
 => nil
2.3.1 :005 > # now you can only see "exit" and "puts 'three'" in the history, you can't see "puts 'two'" or "puts 'one'"

This issue is over two years old, easy to reproduce, extremely obnoxious, _and_ likely to damage the reputation of Pry as a tool. For these reasons, I'd like to think that the Pry team would consider prioritizing it (more highly than new features). I'm at a loss to explain why it isn't important to them (but all of this can also be said about the similar issue #1275, and that issue is also mysteriously unimportant).

[imnithin]

Makes it super messy . No fix yet.

[nitsujri]

Bumping because it's been.... well 6 years 😆. I love ruby, rails, and pry. This is the only issue and a minor one, but 6 years on it still makes copy/paste my commands from another area near daily 😉