How to run IRB.start in context of current class

Question

I've been just going through PragProg Continuous Testing With Ruby, where they talk about invoking IRB in context of current class to inspect the code manually.

However, they quote that if you invoke IRB.start in a class, self is predefined, and refers to the object we were in when start was called which isn't true in my case.

Even for very simple example like

a = "hello"
require 'irb'
ARGV.clear # otherwise all script parameters get passed to IRB
IRB.start

When I try to access the a variable, I get the obvious

NameError: undefined local variable or method `a' for main:Object

It works only when I change a to global variable

$a = "hello"
require 'irb'
ARGV.clear # otherwise all script parameters get passed to IRB
IRB.start

then I can access it

irb(main):001:0> $a
=> 1

Is there any way around this to access local and instance variables in the current class?

Answer 1

I'd suggest trying this in ripl, an irb alternative. The above example works:

a = 'hello'
require 'ripl'
Ripl.start :binding => binding

Note that local variables work because your passing the current binding with the :binding option.

You could possibly do the same in irb, but since it's poorly documented and untested, your chances of doing it cleanly are slim to none.

Answer 2

As you've already discovered, self does not refer to the object where IRB was started, but to the TOPLEVEL_BINDING, which seems to be an instance of the Object class itself.

You can still run an IRB session with a specific class or object as the context, but it's not as simple as just starting IRB.

If you care about is starting IRB with a specific context, then it's really easy to do when you're starting IRB manually. Just start IRB normally and then call the irb method, passing it the object/class you want as the context.

$ irb
irb(main):002:0> require 'myclass'
=> true
irb(main):003:0> irb MyClass
irb#1(MyClass):001:0> self
=> MyClass

You can also start an IRB session programmatically and specify the context, but it's not nearly as easy as it should be because you have to reproduce some of IRB's start-up code. After a lot of experimenting and digging around in the IRB source code, I was able to come up with something that works:

require 'irb'
IRB.setup nil
IRB.conf[:MAIN_CONTEXT] = IRB::Irb.new.context
require 'irb/ext/multi-irb'
IRB.irb nil, self

Answer 3

Instead of global you could use instance variables, e.g.:

require 'irb'
@a = "hello"
ARGV.clear
IRB.start

>> @a
=> "hello"

Answer 4

Use Pry:

a = 'hello'
require 'pry'
binding.pry

Answer 5

Here's how to invoke IRB from your script in the context of where you call IRB.start..

require 'irb'
class C
    def my_method
        @var = 'hi'
        $my_binding = binding
        IRB.start(__FILE__)
    end
end

C.new.my_method

Executing your script will invoke IRB. When you get to the prompt you have one more thing to do...

% ./my_script.rb
irb(main):001:0> @var.nil?
=> true
irb(main):002:0> cb $my_binding
=> #<C:0x000000009da300 @var="hi">
irb(#<C:0x000000009da300>):003:0> @var.nil?
=> false
irb(#<C:0x000000009da300>):004:0> @var
=> "hi"

Enjoy!

Answer 6

As of Ruby 2.4.0, you can do this:

require 'irb'
binding.irb

This will start an IBR REPL where you will have the correct value for self and you will be able to access all local variables and instance variables that are in scope. Type Ctrl+D or quit in order to resume your Ruby program.

Answer 7

My solution for Ruby 2.2.3. It is very similar to Bryant's

def to_s
  "Sample"
end

def interactive
  banana = "Hello"
  @banana = "There"
  require 'irb'
  IRB.setup(nil)
  workspace = IRB::WorkSpace.new(binding)
  irb = IRB::Irb.new(workspace)
  IRB.conf[:MAIN_CONTEXT] = irb.context
  irb.eval_input
end

irb(Sample):001:0> puts banana
Hello
=> nil
irb(Sample):002:0> puts @banana
There
=> nil
irb(Sample):003:0>

I can access local variables and instance variables. The require 'irb' of course could be at the top of the file. The setting of banana and @banana is just to prove I can access them from the irb prompt. The to_s is one method of getting a pretty prompt but there are other choices. And there is no real reason to make a separate method but as it stands, you can plop this in anywhere and it should work.

Answer 8

The ruby-debug-base gem adds a binding_n method to the Kernel module and this will give you access binding object that can be used in an eval to give access to call-stack variables. Remember to issue Debugger.start to turn on call stack tracking.

Here is an example showing its use to introspect what is going on inside irb (a Ruby program). One could put the require's and Debugger.start inside your own Ruby code as well.

$ irb
ruby-1.8.7-p302 > require 'rubygems'
 => true 
ruby-1.8.7-p302 > require 'ruby-debug-base'
 => true 
ruby-1.8.7-p302 > Debugger.start
 => true 
ruby-1.8.7-p302 > puts caller
/tmp/.rvm/rubies/ruby-1.8.7-p302/lib/ruby/1.8/irb/workspace.rb:52  :i  n `irb_binding' #`
/tmp/.rvm/rubies/ruby-1.8.7-p302/lib/ruby/1.8/irb/workspace.rb:52
=> nil 
ruby-1.8.7-p302 > eval "main", binding_n(2)
 => #<Object:0xb7762958 @prompt={:PROMPT_I=>"ruby-1.8.7-p302 > ", :PROMPT_N=>"  ruby-1.8.7-p302 ?> ", :PROMPT_S=>"ruby-1.8.7-p302%l> ", :PROMPT_C=>"ruby-1.8.7-p302 > ", :AUTO_INDENT=>true, :RETURN=>" => %s \n"}> 
ruby-1.8.7-p302 > 

If you are willing to run a patched version of Ruby for 1.9.2 see http://gitnub.com/rocky/rb-threadframe for what I think is better access to the call stack. Rubinius provides this capability built in via Rubinius::VM.backtrace.