Actually, this would mean gathering the information necessary to completely populate a ProcessStatus object (for $?). Seems like a bit too much trouble at the moment (since my patch is working for what I need). I'll probably do this eventually, but not at the moment.
Daniel On Fri, Apr 17, 2009 at 9:04 PM, Daniel Spiewak <djspie...@gmail.com> wrote: > I suppose changing sh would be a better solution. The only disadvantage > there is we need to make sure that anything which would otherwise use system > for invoking potentially-problematic executables should instead use sh. > Optimally, the JRuby guys should eventually adopt something like this for > the canonical system implementation, but until then... > > I'll make the necessary changes in my fork. > > Daniel > > > On Fri, Apr 17, 2009 at 8:17 PM, Assaf Arkin <ar...@intalio.com> wrote: > >> On Fri, Apr 17, 2009 at 11:42 AM, Daniel Spiewak <djspie...@gmail.com >> >wrote: >> >> > I think we should consider this: >> > >> > >> http://github.com/djspiewak/buildr/commit/51280abe5d37c2800ae53828bc0bb3ba5b51d946 >> > >> > The reason being that JRuby's Kernel#system method is fundamentally >> broken >> > (because it is based on java.lang.Runtime.exec). They've managed to >> piece >> > things together so that it's rarely an issue, but problems do surface >> when >> > doing things like the following: >> > >> > system 'scala' >> > >> > If you run this from JRuby, your terminal will freeze and refuse to >> accept >> > any input (except for escape sequences like Ctrl+C). This limitation in >> > Kernel#system basically prevents any sort of working REPL support >> (git:// >> > github.com/djspiewak/buildr.git / interactive-shell). In order to get >> > around this, I propose that Buildr should rewrite the Kernel#system >> > method *when >> > running under JRuby* so that it uses the platform's native `system` >> > function >> > (from the C stdlib). The commit linked above (51280ab) contains the >> > necessary implementation. Note that this commit is basically untested, >> but >> > it seems to work on Mac for everything I've tried so far. >> > >> > Advantages: Buildr's external process dispatch on JRuby will be more >> > predictable and basically in line with what happens on MRI. This will >> > probably resolve/avoid some bugs and certainly opens up a whole new >> series >> > of possibilities (like the interactive shell support). >> > >> > Disadvantages: It introduces a new gem dependency on JRuby (ffi-0.3.2) >> and >> > actually overwrites a core Ruby method. It's the latter that has me the >> > most concerned. Kernel#system is quite foundational to Buildr and Ruby >> in >> > general, so casually monkey-patching in a new implementation is not a >> step >> > which should be taken lightly. >> >> >> I also have a bad feeling about changing Kernel#system, but we can >> certainly >> change sh, which is brought over from Rake. >> >> Assaf >> >> >> > >> > >> > Thoughts? >> > >> > Daniel >> > >> > >