[#JRUBY-2049] backticks launching vi causes unexpected issues in vi

JRuby

backticks launching vi causes unexpected issues in vi

Created: 29/Jan/08 01:42 PM Updated: 23/Apr/08 10:07 AM

Component/s:

Core Classes/Modules

Affects Version/s:

JRuby 1.1RC1

Fix Version/s:

None

Time Tracking:

Not Specified

Environment:

OS X 10.5

Description

« Hide

If you do this:

gem install utility_belt

and then enter regular IRB and do this:

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.

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Damian Steer added a comment - 29/Jan/08 02:55 PM

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.

[ Permalink | « Hide ]

giles bowkett added a comment - 29/Jan/08 03:22 PM

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

[ Permalink | « Hide ]

Damian Steer added a comment - 29/Jan/08 05:46 PM

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.

[ Permalink | « Hide ]

Damian Steer added a comment - 30/Jan/08 03:37 PM

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

[ Permalink | « Hide ]

Ola Bini added a comment - 12/Feb/08 10:01 AM

Seems we're out of luck here. =/

[ Permalink | « Hide ]

Nick Sieger added a comment - 12/Feb/08 11:37 AM

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.