Issue #7536 has been updated by charliesome (Charlie Somerville).

Status changed from Open to Assigned
Assignee set to ko1 (Koichi Sasada)
Priority changed from Normal to High
Target version set to 2.0.0


----------------------------------------
Bug #7536: local variables added to TOPLEVEL_BINDING in -r are broken 
https://bugs.ruby-lang.org/issues/7536#change-34699

Author: Conrad.Irwin (Conrad Irwin)
Status: Assigned
Priority: High
Assignee: ko1 (Koichi Sasada)
Category: 
Target version: 2.0.0
ruby -v: 2.0.0dev (2012-12-09 trunk 38278) [x86_64-linux]


If a library that you require in the -r flag of ruby evals things in TOPLEVEL_BINDING (e.g. RUBY_OPT=-rbundler/setup), then the local variables will show up in TOPLEVEL_BINDING.eval("local_variables"), but they raise a NameError if you try to use them.

A minimal test case is:

$ cat b.rb
TOPLEVEL_BINDING.eval("lib = 2")

$ cat a.rb
puts TOPLEVEL_BINDING.eval("local_variables").inspect
puts TOPLEVEL_BINDING.eval("lib").inspect

$ ruby -r./b.rb a.rb
[:lib]
<main>:in `<main>': undefined local variable or method `lib' for main:Object (NameError)
        from a.rb:2:in `eval'
        from a.rb:2:in `<main>'

This affects ruby 1.9.3 and ruby 2.0.0, I tested with:
 ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-linux]
 ruby 2.0.0dev (2012-12-09 trunk 38278) [x86_64-linux]

Ruby 1.8.7 works fine:
$ ruby -v
ruby 1.8.7 (2012-06-29 patchlevel 370) [x86_64-linux]
$ ruby -r./b.rb a.rb
["lib"]
2

This breaks debugging tools like pry or https://github.com/charliesome/better_errors, which rightly assume that it's safe to do:

    any_binding.eval("local_variables").map{ |x| any_binding.eval("#{x}") }

There are two possible solutions; either remove the variable names from the list of "local_variables", make sure they don't raise a NameError.



-- 
http://bugs.ruby-lang.org/