They may have fixed system() such that using FFI directly wouldn't be necessary anymore. A simple test such as "system 'vim'" from jirb on Windows would confirm.
alex On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme <[email protected]>wrote: > 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 > > >
