Jeff King writes:
> On Sat, Jan 05, 2013 at 09:03:16AM -0500, Jeff King wrote:
> ...
> The downside is that callers of run_command can no longer
> differentiate between a signal received directly by the
> sub-process, and one propagated. However, no caller
> currently cares, and since we already
Jeff King wrote:
>I'd expecting cooking this patch for a while
> would flush out any I missed.
Heh, probably not. ;-) But I tried to examine all the callsites (and
only found the two messages I mentioned), and among the reviewers, I'm
guessing we hit them all.
Ciao,
Jona
On Sat, Jan 05, 2013 at 02:19:09PM -0800, Jonathan Nieder wrote:
> > Documentation/technical/api-run-command.txt | 6 ++
> > editor.c| 2 +-
> > run-command.c | 2 +-
> > 3 files changed, 4 insertions(+), 6 deletions(-)
>
> t/
Hi,
Jeff King wrote:
> When a sub-command dies due to a signal, we encode the
> signal number into the numeric exit status as "signal -
> 128".
[...]
> 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 s
easier for callers. See the patch below. I've tried to
> re-state the somewhat rambling argument from my previous email;
> hopefully it makes sense.
>
> -- >8 --
> Subject: [PATCH] run-command: encode signal death as a positive integer
>
> When a sub-command dies due
m my previous email;
hopefully it makes sense.
-- >8 --
Subject: [PATCH] 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 regula
6 matches
Mail list logo
