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, t开发者_StackOverflow中文版hey 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?
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
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.
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.
Instead of global you could use instance variables, e.g.:
require 'irb'
@a = "hello"
ARGV.clear
IRB.start
>> @a
=> "hello"
Use Pry:
a = 'hello'
require 'pry'
binding.pry
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!
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.
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.
This one is kind of a mash up of all the answers in this thread. Is the smallest piece of code that would produce the behavior requested by the person who asked:
require 'irb'
module Craft
class Console
def start
IRB.setup(__FILE__)
workspace = IRB::WorkSpace.new(self)
IRB::Irb.new(workspace).run(IRB.conf)
end
def hello
puts 'hello world!'
end
end
end
There is no need to clear the ARGV
and also no need for explicitly calling eval_input
.
Here is how the output looks:
bundle exec craft console
irb(#<Craft::Console:0x00007fb0135592c0>):001:0>hello
hello world!
=> nil
精彩评论