JRuby

exec regression in windows since 1.6.0 (?)

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.6.2
  • Fix Version/s: JRuby 1.7.0.RC1
  • Component/s: Windows
  • Labels:
    None
  • Environment:
    jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (Java HotSpot(TM) Client VM 1.6.0_21) [Windows XP-x86-java]
  • Number of attachments :
    0

Description

Running into the following when using the gem gemedit to easily open installed gems in an editor.

What it does is essentially this:

edit_command.rb
      cmd = "#{options[:editor]} ."
      Dir.chdir(spec.full_gem_path) do
        exec cmd
      end

This used to work ok on 1.6.0 under windows. However, now it doesnt seem like exec searches the PATH anymore when firing up the editor. I get:
ERROR: While executing gem ... (Errno::ENOENT)
No such file or directory - cannot execute

If I set the full path to the editor I get the odd effect of the editor opening, but in the current directory where I issue the command, not spec.full_gem_path.

I assume something must have changed with regards to #exec on windows between 1.6.0 and 1.6.2.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Patrik Sundberg added a comment -

Under 1.6.3 it seems the PATH is used to find the executable, but I still get the odd effect of the editor opening in the current dir, not taking the Dir.chdir into account.

I'm executing a bat file. I wonder if that's the issue here. I'll investigate that further.

Show
Patrik Sundberg added a comment - Under 1.6.3 it seems the PATH is used to find the executable, but I still get the odd effect of the editor opening in the current dir, not taking the Dir.chdir into account. I'm executing a bat file. I wonder if that's the issue here. I'll investigate that further.
Hide
Permalink
Patrik Sundberg added a comment -

Not related to bat files. Have a feeling it's somehow related to using "." in the command put to #exec.

I played around with it some more and indeed that is what happens. "." under windows in #exec is not referring to the same current directory as the ruby program is currently running in, it's referring to what current dir was for the process running the ruby program was.

I poked around a little but I'm not sure how "." is treated under windows, exactly how #exec launches the process under windows etc so couldn't narrow it down more.

Overall it seems clear though that #exec on windows does not hand over the state correctly for "." to refer to the same dir as the current dir of the ruby process invoking #exec.

Show
Patrik Sundberg added a comment - Not related to bat files. Have a feeling it's somehow related to using "." in the command put to #exec. I played around with it some more and indeed that is what happens. "." under windows in #exec is not referring to the same current directory as the ruby program is currently running in, it's referring to what current dir was for the process running the ruby program was. I poked around a little but I'm not sure how "." is treated under windows, exactly how #exec launches the process under windows etc so couldn't narrow it down more. Overall it seems clear though that #exec on windows does not hand over the state correctly for "." to refer to the same dir as the current dir of the ruby process invoking #exec.
Hide
Permalink
Thomas E Enebo added a comment -

In JRuby 1.6.1 we started to use native exec via jnr-posix. Each point release has fixed issues related to this and I think you just uncovered the last one (knock on wood). Work-around until 1.6.4: If you do Xnative.enabled=false, then it will make JRuby run in pure-Java mode which should make relative exec work again (although possibly with consequences since nothing native will be called anymore <- not likely a problem for most).

Show
Thomas E Enebo added a comment - In JRuby 1.6.1 we started to use native exec via jnr-posix. Each point release has fixed issues related to this and I think you just uncovered the last one (knock on wood). Work-around until 1.6.4: If you do Xnative.enabled=false, then it will make JRuby run in pure-Java mode which should make relative exec work again (although possibly with consequences since nothing native will be called anymore < - not likely a problem for most).
Hide
Permalink
Patrik Sundberg added a comment -

Cool - thanks.

Show
Patrik Sundberg added a comment - Cool - thanks.
Hide
Permalink
Patrik Sundberg added a comment -

Hi. Just a friendly poke about this "last" jnr-posix issue. ThanksWith 1.6.5 around the corner etc. Thanks

Show
Patrik Sundberg added a comment - Hi. Just a friendly poke about this "last" jnr-posix issue. ThanksWith 1.6.5 around the corner etc. Thanks
Hide
Permalink
Patrik Sundberg added a comment -

This is still a rather nasty issue on Windows. Saw it didn't make 1.6.5 - hoping for 1.6.6

Show
Patrik Sundberg added a comment - This is still a rather nasty issue on Windows. Saw it didn't make 1.6.5 - hoping for 1.6.6
Hide
Permalink
Ben Browning added a comment - - edited

We're still seeing the same "No such file or directory - cannot execute" error when trying to exec a .bat file to start TorqueBox on Windows under JRuby 1.6.5. The striked through workaround above of setting -Xnative.enabled=false does workaround the issue and lets TorqueBox boot but will likely cause other issues during runtime with native disabled.

Show
Ben Browning added a comment - - edited We're still seeing the same "No such file or directory - cannot execute" error when trying to exec a .bat file to start TorqueBox on Windows under JRuby 1.6.5. The striked through workaround above of setting -Xnative.enabled=false does workaround the issue and lets TorqueBox boot but will likely cause other issues during runtime with native disabled.
Hide
Permalink
Thomas E Enebo added a comment -

Marking as a blocker since it affects real software and I am fairly sure I know at least why it broke.

Show
Thomas E Enebo added a comment - Marking as a blocker since it affects real software and I am fairly sure I know at least why it broke.
Hide
Permalink
Ben Browning added a comment -

Our TorqueBox issue may be slightly different than the original issue since we're not referencing "." in the command but instead trying to exec a .bat file specified by an absolute path. I found a bug in the WindowsHelpers.isBatch command in jnr-posix and am testing whether fixing that bug fixes our ability to exec .bat files right now.

Show
Ben Browning added a comment - Our TorqueBox issue may be slightly different than the original issue since we're not referencing "." in the command but instead trying to exec a .bat file specified by an absolute path. I found a bug in the WindowsHelpers.isBatch command in jnr-posix and am testing whether fixing that bug fixes our ability to exec .bat files right now.
Hide
Permalink
Ben Browning added a comment -

Fixing WindowsHelper.isBatch to properly check for .bat / .com extensions didn't fix the "cannot execute" issue - will need further investigation into what's going on.

Show
Ben Browning added a comment - Fixing WindowsHelper.isBatch to properly check for .bat / .com extensions didn't fix the "cannot execute" issue - will need further investigation into what's going on.
Hide
Permalink
Thomas E Enebo added a comment -

Ben, can you give me a patch for the error in isBatch? Even if it does not completely fix the issue you discovered something I suspect is still wrong with that code?

Show
Thomas E Enebo added a comment - Ben, can you give me a patch for the error in isBatch? Even if it does not completely fix the issue you discovered something I suspect is still wrong with that code?
Hide
Permalink
Ben Browning added a comment -

I believe the isBatch code is still wrong, but it didn't fix anything in my testing. Ultimately my problem involved passing an empty string as one of the arguments to exec. So, that's likely a separate bug. I think the right thing to do is for me to create a JIRA for each of these bugs and attach separate patches to each JIRA.

Show
Ben Browning added a comment - I believe the isBatch code is still wrong, but it didn't fix anything in my testing. Ultimately my problem involved passing an empty string as one of the arguments to exec. So, that's likely a separate bug. I think the right thing to do is for me to create a JIRA for each of these bugs and attach separate patches to each JIRA.
Hide
Permalink
Oliver Ferrigni added a comment -

I think this issue still exists in 1.6.6. I opened http://jira.codehaus.org/browse/JRUBY-6432 before finding this and closing as duplicate.

Show
Oliver Ferrigni added a comment - I think this issue still exists in 1.6.6. I opened http://jira.codehaus.org/browse/JRUBY-6432 before finding this and closing as duplicate.
Hide
Permalink
Celso Dantas added a comment -

(copying my comment to here)

The error persist in JRuby 1.6.7

Can't run multiple arguments in Kernel.exec.

Ex:

> Kernel.exec("rspec", "spec")
Errno::ENOENT: No such file or directory - cannot execute
from org/jruby/RubyKernel.java:1709:in `exec'
from (irb):1:in `evaluate'
from org/jruby/RubyKernel.java:1083:in `eval'
from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:158:in `eval_input'
from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:271:in `signal_status'
from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:155:in `eval_input'
from org/jruby/RubyKernel.java:1410:in `loop'
from org/jruby/RubyKernel.java:1183:in `catch'
from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:154:in `eval_input'
from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:71:in `start'
from org/jruby/RubyKernel.java:1183:in `catch'
from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:70:in `start'
from c:/jruby-1.6.7/bin/irb:13:in `(root)'

Show
Celso Dantas added a comment - (copying my comment to here) The error persist in JRuby 1.6.7 Can't run multiple arguments in Kernel.exec. Ex: > Kernel.exec("rspec", "spec") Errno::ENOENT: No such file or directory - cannot execute from org/jruby/RubyKernel.java:1709:in `exec' from (irb):1:in `evaluate' from org/jruby/RubyKernel.java:1083:in `eval' from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:158:in `eval_input' from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:271:in `signal_status' from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:155:in `eval_input' from org/jruby/RubyKernel.java:1410:in `loop' from org/jruby/RubyKernel.java:1183:in `catch' from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:154:in `eval_input' from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:71:in `start' from org/jruby/RubyKernel.java:1183:in `catch' from c:/jruby-1.6.7/lib/ruby/1.8/irb.rb:70:in `start' from c:/jruby-1.6.7/bin/irb:13:in `(root)'
Hide
Permalink
Charles Oliver Nutter added a comment -

This is fixed by a recent update of jffi.

Show
Charles Oliver Nutter added a comment - This is fixed by a recent update of jffi.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Patrik Sundberg
Vote (1)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: