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 >
