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

        Hide
        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
        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
        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
        Patrik Sundberg added a comment -

        Cool - thanks.

        Show
        Patrik Sundberg added a comment - Cool - thanks.
        Hide
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: