Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: JRuby 1.1RC1
    • Fix Version/s: None
    • Component/s: Core Classes/Modules
    • Labels:
      None
    • Environment:
      OS X 10.5
    • Number of attachments :
      0

      Description

      If you do this:

      gem install utility_belt

      and then enter regular IRB and do this:

      vi

      you should then be able to enter arbitrary code in vi, which then executes (after you close the file) in the IRB session you were in.

      however, if you do it from jirb, the vi which is launched has this weird inability to perceive the escape key.

      utility belt also has similar shortcuts for emacs and TextMate. on my system TextMate behaves as expected, but emacs fails to launch at all.

      in #jruby headius noted this is probably related to an issue with readline.

        Activity

        Hide
        Damian Steer added a comment -

        The issue seems to be the way our system call works. (Caution: I couldn't escape from vi!)

        lewis:jruby pldms$ ruby -e 'system("vi /tmp/vi_test")' # all works as expected
        lewis:jruby pldms$ jruby -e 'system("vi /tmp/vi_test")'
        Vim: Warning: Output is not to a terminal
        Vim: Warning: Input is not from a terminal
        ... acts very oddly ...
        

        Presumably the IO hookup is the problem, but this may be out of our hands. Trying a pure java test.

        Show
        Damian Steer added a comment - The issue seems to be the way our system call works. (Caution: I couldn't escape from vi!) lewis:jruby pldms$ ruby -e 'system("vi /tmp/vi_test")' # all works as expected lewis:jruby pldms$ jruby -e 'system("vi /tmp/vi_test")' Vim: Warning: Output is not to a terminal Vim: Warning: Input is not from a terminal ... acts very oddly ... Presumably the IO hookup is the problem, but this may be out of our hands. Trying a pure java test.
        Hide
        giles bowkett added a comment -

        yeah, actually, I should have mentioned that - it locked me in vi also. I had to close the terminal window to make my escape.

        Show
        giles bowkett added a comment - yeah, actually, I should have mentioned that - it locked me in vi also. I had to close the terminal window to make my escape.
        Hide
        Damian Steer added a comment -

        So this:

        import static java.lang.System.err;
        import java.io.BufferedInputStream;
        public class Test {
        	public static void main(String... args) throws Exception {
        		err.println("We begin");
        		Process process = Runtime.getRuntime().exec(new String[] {"vi" , "/tmp/hello"});
        		BufferedInputStream is = new BufferedInputStream(process.getInputStream());
        		byte[] arr = new byte[300];
        		while (is.read(arr,0,300) != -1) {
        			err.write(arr);
        		}
        		err.println(process.exitValue());
        	}
        }
        

        seems to have the same problem. Hrm.

        Show
        Damian Steer added a comment - So this: import static java.lang.System.err; import java.io.BufferedInputStream; public class Test { public static void main(String... args) throws Exception { err.println("We begin"); Process process = Runtime.getRuntime().exec(new String[] {"vi" , "/tmp/hello"}); BufferedInputStream is = new BufferedInputStream(process.getInputStream()); byte[] arr = new byte[300]; while (is.read(arr,0,300) != -1) { err.write(arr); } err.println(process.exitValue()); } } seems to have the same problem. Hrm.
        Hide
        Damian Steer added a comment -

        This looks like a "can't fix" to me. The only available means to launch processes is limited:

        The methods that create processes may not work well for special processes on certain native platforms, such as native windowing processes, daemon processes, Win16/DOS processes on Microsoft Windows, or shell scripts. The created subprocess does not have its own terminal or console.

        http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Process.html

        Show
        Damian Steer added a comment - This looks like a "can't fix" to me. The only available means to launch processes is limited: The methods that create processes may not work well for special processes on certain native platforms, such as native windowing processes, daemon processes, Win16/DOS processes on Microsoft Windows, or shell scripts. The created subprocess does not have its own terminal or console. http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Process.html
        Hide
        Ola Bini added a comment -

        Seems we're out of luck here. =/

        Show
        Ola Bini added a comment - Seems we're out of luck here. =/
        Hide
        Nick Sieger added a comment -

        The only other possibility is a spawn/execve system call via JNA, but I don't know if we'd want to do that all the time.

        Show
        Nick Sieger added a comment - The only other possibility is a spawn/execve system call via JNA, but I don't know if we'd want to do that all the time.

          People

          • Assignee:
            Ola Bini
            Reporter:
            giles bowkett
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: