I can contact the jruby folks and see if a jruby update would help - JFFI is now 1.0 btw, while it was 0.4 in 1.4.0.
On Mon, Mar 1, 2010 at 08:12, Alex Boisvert <[email protected]> wrote: > On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt < > [email protected]> wrote: > > > It would be nice if BUILDR-348 could be resolved for 1.4.0. We are > planning > > on using buildr as internally running on jruby 1.4. Right now this issue > > means I will either have to maintain a custom buildr build or have every > > developer patch the buildr installation by hand. > > > > Any idea on the root cause of this problem? Does commenting out that one > > line have any other side effects? > > > > The issue is that JRuby use{s,d} the JVM's System.exec() call to spawn > external processes, which isn't 100% equivalent to Unix system() call. For > instance, if you spawned a process like 'vim' or a language shell like > 'scala' or 'irb', then you wouldn't be able to interact with the > sub-process > correctly due to incomplete redirection of all terminal capabilities. > > To solve this, we override the system() call to circumvent the JRuby's > system call and directly call the native system() using FFI. > > I don't know what's the state of things on JRuby 1.4.0 + Windows but some > internals seem to have changed which is why we're getting the error > described in BUILDR-348. Somebody needs to investigate what works/doesn't > work on Windows -- the workaround I provided on BUILDR-348 simply reverts > to > using the standard system() implementation, which works for most things but > not shelling out to interactive apps. > > alex >
