jruby fails to report process exit status correctly

I assume the latter "smartness" isn't something you think we should make un-smart. Actually this is probably Java being smart for us, so I'm not sure we could dumb it down if we wanted to.

The process exit stuff should be fixed for sure though.

> I assume the latter "smartness" isn't something you think we should make un-smart.

Definitely not, I just wanted to point out that it behaves a little different than mri. I think this should be documented somewhere, but I don't know what a proper place would be. Is there a document on the differences between mri and jruby? I know, in an ideal world, we'd have no need for such document...

You'd be my hero if you started such a page (or updated one that might be there?) on the JRuby wiki. Just google "jrubywiki" and you'll find it. I agree this is a good item to put there, and we should make an effort to have a complete list by JRuby 1.0.

You already said I'd be your hero if I fixed the bugs I reported when I joined JRuby mailing list (and I did). = ) So now I guess I'm doubly your hero:

http://headius.com/jrubywiki/index.php/Differences_between_mri_and_jruby

It is linked to from the main wiki page. Now the page contains this process launching thing and missing continuations, but I guess there will be more.

Not going to be in RC2, and in danger of falling off 1.0. Assigning to Nick, since he's been closest to the process-launching code. It could be something simple.

I did some digging to figure out what's going on here.

The following program gives a better idea of why things go for (I just use Python to generate the exit code ):

puts system('python -c "import sys; sys.exit(2)"')
puts $?
puts $?>>8

CRuby on Windows and Linux prints:

false
512
2

JRuby on Windows and Linux prints:

false
2
0

The value put into $? is the return value of waitFor() called on a Process returned from ShellLauncher.run(IRubyObject[]). This Process can either be a ScriptThreadProcess or whatever is returned by Runtime.getRuntime().exec(...). From the OpenJDK sources I can see that this is a java.lang.ProcessImpl on Windows and a java.lang.UNIXProcess on Solaris and Linux.

On Windows, ProcessImpl's waitFor ends up calling the Win32 API function GetExitCodeProcess. On Solaris/Linux, they do all kinds of interesting things with the return value of waitpid, depending on whether the exit code indicates that the process was terminated by a signal.

In conclusion, it looks like some shifting and/or other mangling of the exit code needs to be done by JRuby before it puts it into $? (at least when using Java's Process implementation; not sure what has to happen for ScriptThreadProcess).

So would it be sufficient to simply << 8 the exit code before assigning to $??

I'd say "probably". It might be worth doing a quick investigation to figure out how MRI came up with that number – do they only shift it (why?) or are there other things afoot.

Test script:

#!/usr/bin/env python
import os
import signal
os.kill(os.getpid(), signal.SIGHUP)

JRuby:

[albert@dogbert ~]$ jruby -e 'system("./signal.py"); puts $?'
129

MRI:

[albert@dogbert ~]$ ruby -e 'system("./signal.py"); puts $?'
1

SIGHUP is signal number 1.

I could be wrong, but it looks like JRuby is also missing a few Process::Status pieces like signaled? and stopsig.

Albert: Could you file a separate bug for the missing process methods? Some we can't support, but it would be good to at least have a bug out there for them.

Unfortunately I don't think we're going to be able to emulate the signaled? behavior. For now, the to_i and to_s methods will return exitstatus << 8, which matches MRI, except for when the process is signaled.

I just took the latest from svn and there's something broken:

C:\programs\jruby>ruby -e "system('ruby -e \"exit(2)\"');print $?>>8"
2
C:\programs\jruby>jruby -e "system('ruby -e \"exit(2)\"');print $?>>8"
\"');print $?>>8") was unexpected at this time.

Since it works w/ mri (the first line) I don't think it's a win command prompt issue.

Looks like it's a problem with how Java in Windows handles parentheses in CLI parameters?

Ummm... I seem to still have this issue under JRuby 1.40 and Windows. Had it indeed been fixed or did it regress?

>jruby -e "system('ruby -e \"exit(2)\"');print $?>>8"
0

>ruby -e "system('ruby -e \"exit(2)\"');print $?>>8"
2

Same here: the issue is still here with jruby 1.4.0 on windows