Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing environment hash to Open3#popen3 causes IOError #1547

rabbitt opened this issue Mar 6, 2014 · 1 comment

Passing environment hash to Open3#popen3 causes IOError #1547

rabbitt opened this issue Mar 6, 2014 · 1 comment


Copy link

rabbitt commented Mar 6, 2014

Test Code

require 'open3'
require 'pp'

ENV.keys.collect { |k| ENV.delete(k) }
result = Open3.popen3({'A' => 'B', 'C' => 'D'}, '/usr/bin/env') do |i, out, err, thr|
  output = { }
  error  = { }

  [ output.value, error.value, thr.value ]

pp result

Expected Results (based on tests with MRI 1.9.3, 2.0.0 and 2.1.1):

["A=B\nC=D\n", "", #<Process::Status: pid 46225 exit 0>]

Actual results (same with both jruby 1.7.10 and 1.7.11):

IOError: Cannot run program "{"A"=>"B", "C"=>"D"}" (in directory "/Users/rabbitt/personal/repos/git-hooks"): error=2, No such file or directory
  popen3 at org/jruby/
  popen3 at /Users/rabbitt/.rvm/rubies/jruby-1.7.11/lib/ruby/1.9/open3.rb:74
  (root) at test.rb:5
Copy link

headius commented Dec 2, 2014

Fixed for 1.7.17. I will add a test to MRI, since open3 is no longer part of RubySpec proper and we don't run the rubysl specs.

@headius headius closed this as completed Dec 2, 2014
@headius headius assigned headius and unassigned atambo Dec 2, 2014
headius added a commit that referenced this issue Dec 2, 2014
MRI manages the frame's self differently, just saving it into the
binding and then putting it in the sole global state field that
represents the current thread's active frame. In our case, we use
the entire Frame object as a carrier for frame data, so we need
to keep the object the same for mutable frame fields like backref
to propagate. As a result, the only fix possible for this on 1.7
is to change the self back after instance_eval.

We may be able to fix this better on master, where the runtime
has been restructured and may support a more correct notion of the
current frame's self.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants