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

Closed
rabbitt opened this Issue Mar 6, 2014 · 1 comment

Comments

Projects
None yet
4 participants
@rabbitt
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 = Thread.new { out.read }
  error  = Thread.new { err.read }

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

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/RubyIO.java:4375
  popen3 at /Users/rabbitt/.rvm/rubies/jruby-1.7.11/lib/ruby/1.9/open3.rb:74
  (root) at test.rb:5

@atambo atambo added this to the JRuby 1.7.13 milestone Apr 27, 2014

@atambo atambo self-assigned this Apr 27, 2014

@enebo enebo modified the milestones: JRuby 1.7.14, JRuby 1.7.13 Jun 24, 2014

@enebo enebo modified the milestones: JRuby 1.7.14, JRuby 1.7.15 Aug 27, 2014

@headius headius modified the milestones: JRuby 1.7.17, JRuby 1.7.15 Dec 2, 2014

headius added a commit that referenced this issue Dec 2, 2014

@headius

This comment has been minimized.

Copy link
Member

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 Dec 2, 2014

@headius headius assigned headius and unassigned atambo Dec 2, 2014

headius added a commit that referenced this issue Dec 2, 2014

Less broken but more grosser fix for #1290 and #1547.
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
You can’t perform that action at this time.