|
|
|
> 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)"') CRuby on Windows and Linux prints: false JRuby on Windows and Linux prints: false 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 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 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" 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?
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
The process exit stuff should be fixed for sure though.