On May 16, 2:02pm, mart...@google.com (Martin Buchholz) wrote: -- Subject: Re: vfork instead of fork for fork+exec?

| On Sat, May 16, 2009 at 11:56, Charles Oliver Nutter | <char...@sun.com> wrote: | > Christos Zoulas wrote: | >> | >> On BSD vfork() does not share file descriptors, current working | >> directory, and signals, and as the following program shows environment | >> too so all the items are fine (and it is trivial to write code that | >> proves this). If that was not the case (file descriptors were shared | >> for example), vfork() would be useless. =A0Even the shell does not | >> (because it cannot) use vfork() in every situation, but only when | >> it can. I don't know if it is worth the trouble of using vfork() | >> in java when it is possible, since fork() is not a very common | >> operation in java programs (I think). | > | > The reason it came up for me is that we're trying to make subprocess | > launching not suck in JRuby. For example, there's no way with current | > process APIs on the JVM to launch a program like vim that needs a real | > console to function properly. Using straight-up fork+exec allows that to | > work: | > | > http://blog.headius.com/2009/05/fork-and-exec-on-jvm-jruby-to-rescue.html= | | | Are you aware of | http://download.java.net/jdk7/docs/api/java/lang/ProcessBuilder.html#inheri= | tIO() | | In JDK6, you can do something non-portable like | | Runtime.exec("/bin/bash", "-c", | "exec /usr/bin/vim < /proc/$PPID/0 > /proc/$PPID/1 2>/proc/$PPID/2")

You mean /proc/$PPID/fd/<n>, but I guess it is prolly better in this case to just use /dev/tty, both from a portability perspective and also because you are going to fail gracefully if your process does not have a tty.

christos