Hi Jonathan, On 2012-08-02 11:03:11 -0700, Jonathan Nieder wrote: > Vincent Lefevre wrote: > > > Severity: grave > > Justification: causes non-serious data loss > > Can you explain that more precisely? At first glance it seems like an > ordinary important bug.
Emacs is often called by other programs, and possibly from a /bin/sh script, with postprocessing. Here's a simple example: #!/bin/sh trap 'true' INT sh -c 'emacs -nw tmpfile; mv tmpfile newfile' rm -f tmpfile cat newfile rm -f newfile If Ctrl-G is typed in Emacs, the data are lost. Even though a correction could be done on such a simple example, in real applications, this is less obvious. And how do we do the difference between (1) a real SIGINT from Ctrl-C, meaning that the user is no longer interested in the data and clean-up can be done, and (2) a SIGINT coming from a bug, meaning that temporary files should be left on the disk and the user should guess where his data are and what they mean? > http://unix.org/2008edition/ tells me: > > When a command is in an asynchronous list, it shall inherit from the > shell a signal action of ignored (SIG_IGN) for the SIGQUIT and > SIGINT signals, and may inherit a signal mask in which SIGQUIT and > SIGINT are blocked. Otherwise, the signal actions and signal mask > inherited by the command shall be the same as those inherited by the > shell from its parent unless a signal action is modified by the trap > special built-in (see trap ) This paragraph is about signals inherited by the command. Here the question is what the shell should do with SIGINT/SIGQUIT signals it receives while it is executing a command which is not killed by the signal? Not that how the command is affected by the signal is important. See the difference between: #!/bin/sh trap 'true' INT bash -c 'date > tmpfile; sleep 5; mv tmpfile newfile' rm -f tmpfile cat newfile rm -f newfile with Ctrl-C during the "sleep 5", and: #!/bin/sh trap 'true' INT bash -c 'date > tmpfile; emacs -nw; mv tmpfile newfile' rm -f tmpfile cat newfile rm -f newfile with Ctrl-G in Emacs. You can also try: #!/bin/sh trap 'true' INT bash -c 'date > tmpfile; gdb; mv tmpfile newfile' rm -f tmpfile cat newfile rm -f newfile with Ctrl-C in gdb. If bash is replaced by dash, one always gets a failure, not just in the first case. Since there was a similar problem with zsh and GNU Emacs under Mac OS X (and I really lost data several times, until I identified the problem, but contrary to here, the problem was occurring with all Emacs versions[*]), I now remember this page: http://www.cons.org/cracauer/sigint.html It probably gives the answer of what should be done. [*] http://www.zsh.org/mla/workers/2009/msg00926.html > How about this patch (which at least gets rid of a mysterious code > artifact)? This is worse: Ctrl-G in emacs kills emacs! -- Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
