Bug #7536: local variables added to TOPLEVEL_BINDING in -r are broken

• Status: Closed
• Assignee: ko1 (Koichi Sasada)
• Target version: 2.0.0
• ruby -v: 2.0.0dev (2012-12-09 trunk 38278) [x86_64-linux]

[Conrad.Irwin (Conrad Irwin)]

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]

:in `': undefined local variable or method `lib' for main:Object (NameError) from a.rb:2:in `eval' from a.rb:2:in `'

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.

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

[ko1 (Koichi Sasada)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

This issue was solved with changeset r38529.
Conrad, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

---

• ruby.c (process_options): need to acquire env from TOPLEVEL_BINDING
  each time.
  bind->env' may update after eval()'.
  [Bug #7536]