Bug #7536

local variables added to TOPLEVEL_BINDING in -r are broken

Added by Conrad Irwin over 1 year ago. Updated over 1 year ago.

[ruby-core:50701]
Status:Closed
Priority:High
Assignee:Koichi Sasada
Category:-
Target version:2.0.0
ruby -v:2.0.0dev (2012-12-09 trunk 38278) [x86_64-linux] Backport:

Description

If a library that you require in the -r flag of ruby evals things in TOPLEVELBINDING (e.g. RUBYOPT=-rbundler/setup), then the local variables will show up in TOPLEVELBINDING.eval("localvariables"), 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 TOPLEVELBINDING.eval("localvariables").inspect
puts TOPLEVEL_BINDING.eval("lib").inspect

$ ruby -r./b.rb a.rb
[:lib]
:in <main>': undefined local variable or methodlib' 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) [x8664-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.

Associated revisions

Revision 38529
Added by Koichi Sasada over 1 year ago

  • ruby.c (processoptions): need to acquire env from TOPLEVELBINDING each time. bind->env' may update aftereval()'. [Bug #7536]

Revision 38530
Added by Yui NARUSE over 1 year ago

Add test for r38529 [Bug #7536]

History

#1 Updated by Charlie Somerville over 1 year ago

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

#2 Updated by Koichi Sasada over 1 year ago

  • 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 (processoptions): need to acquire env from TOPLEVELBINDING each time. bind->env' may update aftereval()'. [Bug #7536]

Also available in: Atom PDF