On Sun, Nov 11, 2012 at 10:48:46AM -0500, Jeff King wrote:
> Silly me. When I thought through the impact of Paul's patch, I knew that
> we would notice signal death of the editor. But I totally forgot to
> consider that the blocked signal is inherited by the child process. I
> think we just need t
jeff wrote:
> On Sun, Nov 11, 2012 at 10:48:46AM -0500, Jeff King wrote:
>
> > Silly me. When I thought through the impact of Paul's patch, I knew that
> > we would notice signal death of the editor. But I totally forgot to
> > consider that the blocked signal is inherited by the child proces
On Sun, Nov 11, 2012 at 11:31:00AM -0500, Jeff King wrote:
>
> Here's a series that I think should resolve the situation for everybody.
>
> [1/5]: launch_editor: refactor to use start/finish_command
>
> The cleanup I sent out a few minutes ago.
>
> [2/5]: launch_editor: ignore SIGINT while
krzysztof wrote:
> On Sun, Nov 11, 2012 at 11:31:00AM -0500, Jeff King wrote:
> >
> > Here's a series that I think should resolve the situation for everybody.
> >
> > [1/5]: launch_editor: refactor to use start/finish_command
> >
> > The cleanup I sent out a few minutes ago.
> >
> >
On Sun, Nov 11, 2012 at 03:24:19PM -0500, Paul Fox wrote:
> krzysztof wrote:
> > Looks ok, but what about SIGQUIT? Some editors like GNU ed (0.4 and 1.6)
> > ignore SIGQUIT, and after SIGQUIT git dies, but editor is still running.
> > After pressing any key ed receives -EIO and prints "stdin: In
Krzysztof Mazur writes:
> That's why I'm proposing in case of SIGQUIT just killing the editor
> (SIGTERM is sufficient for ed).
>
> So git will ignore SIGINT, but die on SIGQUIT (and kill editor
> that ignores SIGQUIT).
system(3) also ignores SIGQUIT.
Andreas.
--
Andreas Schwab, sch...@linux-
6 matches
Mail list logo