On Sat, Jun 1, 2013 at 12:01 PM, Jeff King <p...@peff.net> wrote: > On Sat, Jun 01, 2013 at 09:30:50AM -0500, Felipe Contreras wrote:
>> commit 709ca730f8e093005cc882bfb86c0ca9c83d345b >> Author: Jeff King <p...@peff.net> >> Date: Sat Jan 5 09:49:49 2013 -0500 >> >> run-command: encode signal death as a positive integer >> >> When a sub-command dies due to a signal, we encode the >> signal number into the numeric exit status as "signal - >> 128". This is easy to identify (versus a regular positive >> error code), and when cast to an unsigned integer (e.g., by >> feeding it to exit), matches what a POSIX shell would return >> when reporting a signal death in $? or through its own exit >> code. >> >> So we have a negative value inside the code, but once it >> passes across an exit() barrier, it looks positive (and any >> code we receive from a sub-shell will have the positive >> form). E.g., death by SIGPIPE (signal 13) will look like >> -115 to us in inside git, but will end up as 141 when we >> call exit() with it. And a program killed by SIGPIPE but run >> via the shell will come to us with an exit code of 141. > > Your patch changes the error code that is propagated via exit() in this > case. We cannot know "nobody is checking for the specific code", because > the list of callers is every shell script or program which execs git. > Some of them do care about the exit code. I can give an example of a > case I have that cares, but I do not think it is even important. The > point is that we would be regressing an existing interface, and cannot > know who is broken by it. Of course we can know, by going forward with the change, and quite often that's the only way to know for sure. But if it's true what you said that we haven't changed what the process returns, then it doesn't make sense to attempt going forward, because we have no reference point about the likelihood of scripts relying on specific exit codes. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
