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
>> >
>>
>
>

Reply via email to