<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:11px">It turns out that the exit code issue appears to be more complicated because of how signals are encoded by wait and the interactions with the shell. See the following: </span><a href="http://www.ogf.org/pipermail/drmaa-wg/2008-November/000965.html" target="_blank" style="font-family:arial,sans-serif;font-size:11px">http://www.ogf.org/pipermail/drmaa-wg/2008-November/000965.html</a><div style="font-family:arial,sans-serif;font-size:11px">
<div><br></div><div>If we return "ret" when the child process is signaled, then a "kill -1 childpid" will return a value of 1, and so it will not be possible to distinguish that with the child process returning with exit code 1. Alternatively, we could add 128 to the return value , which is what the shell does, when a child process is signaled. However, I don't know if that would work for all shells (I tried bash, and bash does return the exit code correctly, i.e., unmodified). Another option is to simply return a value different from 1 (e.g., 2), to indicate that the child process was signaled. This is similar to the way grep returns different exit error codes depending on whether the pattern was not found or the file was not found.<div>
<div><br></div><div>Thanks</div></div></div><div>Ashvin</div></div></div>