You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If bundle exec is running in a JVM prepared by drip, very bad things happen. The exec call invokes calls drip just as if you'd typed a java command in the shell. The problem is that drip will then try pull another JVM out of the cache and run that as normal, which does not play well with the I/O redirection that drip uses to work. As a result, whatever command you passed to bundle exec, in my case rspec but it could be anything, runs but does not produce any output in the terminal window.
I think the correct behavior would be to detect this recursion and handle it differently. I've prepared a proof of concept fix which feels rather like a hack, but perhaps will prompt someone better versed in the art of shell scripting to suggest a proper solution. Pull request coming shortly.
The text was updated successfully, but these errors were encountered:
anelson
added a commit
to anelson/drip
that referenced
this issue
Feb 1, 2015
I'm running the latest Drip 0.25.0 with JRuby 1.7.18 on OS X Yosemite.
I have a simple Ruby gem library project which I'm running with JRuby. Part of my workflow includes running
bundle exec rspec
to run my RSpec tests.bundle exec
is a nasty little command. You can see from the Bundler source code at https://github.com/bundler/bundler/blob/d4bde24effb590c779969e9e723fd05682de4a14/lib/bundler/cli/exec.rb#L22 that it operates by mucking with the process environments variables a bit (to influence the Ruby load paths), and then basically reboots the JRuby instance by callingKernel.exec
. This is the equivalent of anexec
method call.If
bundle exec
is running in a JVM prepared by drip, very bad things happen. Theexec
call invokes callsdrip
just as if you'd typed ajava
command in the shell. The problem is that drip will then try pull another JVM out of the cache and run that as normal, which does not play well with the I/O redirection that drip uses to work. As a result, whatever command you passed tobundle exec
, in my caserspec
but it could be anything, runs but does not produce any output in the terminal window.I think the correct behavior would be to detect this recursion and handle it differently. I've prepared a proof of concept fix which feels rather like a hack, but perhaps will prompt someone better versed in the art of shell scripting to suggest a proper solution. Pull request coming shortly.
The text was updated successfully, but these errors were encountered: