Re: [PATCH 0/5] ignore SIGINT while editor runs

2012-11-11 Thread Paul Fox
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 process. I
   think we just need to move the signal() call to after we've forked. Like
   this (on top of Paul's patch):
   [...]
   Note that this will give you a slightly verbose message from git.
   Potentially we could notice editor death due to SIGINT and suppress the
   message, under the assumption that the user hit ^C and does not need to
   be told.
  
  Here's a series that I think should resolve the situation for everybody.

thanks!  i've tested -- this certainly scratches my initial itch.

ack,
paul

  
[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 the editor has control
  
  Paul's patch rebased on my 1/5.
  
[3/5]: run-command: drop silent_exec_failure arg from wait_or_whine
[4/5]: run-command: do not warn about child death by SIGINT
[5/5]: launch_editor: propagate SIGINT from editor to git
  
  Act more like current git when the editor dies from SIGINT.
  
  -Peff
  --
  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

=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 56.3 degrees)
--
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


Re: [PATCH 0/5] ignore SIGINT while editor runs

2012-11-11 Thread Paul Fox
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.
   
 [2/5]: launch_editor: ignore SIGINT while the editor has control
   
   Paul's patch rebased on my 1/5.
   
 [3/5]: run-command: drop silent_exec_failure arg from wait_or_whine
 [4/5]: run-command: do not warn about child death by SIGINT
 [5/5]: launch_editor: propagate SIGINT from editor to git
   
   Act more like current git when the editor dies from SIGINT.
   
  
  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: Input/output
  error. GNU ed 1.6 then exits, but ed 0.4 prints this error forever.
  Maybe git should kill the editor in such case?

there's certainly lots of precedent for treating SIGINT and SIGQUIT
the same.  but there's also some merit to saying that if the user
knows to send SIGQUIT instead of SIGINT, they may well have a reason. 
(after all, if we always treat them the same, there's no point in
having both.)

the em editor (linus' microemacs) behaves as you describe ed 0.4 does,
except without the error message -- it just spins silently getting EIO
from reading stdin.  i think em needs to be fixed, and it sounds like
GNU ed already has been.  (unless i misunderstand the relationship of
0.4 and 1.6.)

paul

  
  Krzysiek
  --
  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

=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 57.2 degrees)
--
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


Re: [PATCH 0/5] ignore SIGINT while editor runs

2012-11-11 Thread Krzysztof Mazur
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: Input/output
   error. GNU ed 1.6 then exits, but ed 0.4 prints this error forever.
   Maybe git should kill the editor in such case?
 
 there's certainly lots of precedent for treating SIGINT and SIGQUIT
 the same.  but there's also some merit to saying that if the user
 knows to send SIGQUIT instead of SIGINT, they may well have a reason. 
 (after all, if we always treat them the same, there's no point in
 having both.)

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).

 
 the em editor (linus' microemacs) behaves as you describe ed 0.4 does,
 except without the error message -- it just spins silently getting EIO
 from reading stdin.  i think em needs to be fixed, and it sounds like
 GNU ed already has been.  (unless i misunderstand the relationship of
 0.4 and 1.6.)

Yes, the version 1.6 is fixed, it just prints an error once and exits.

Krzysiek
--
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


Re: [PATCH 0/5] ignore SIGINT while editor runs

2012-11-11 Thread Andreas Schwab
Krzysztof Mazur krzys...@podlesie.net 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-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
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