On 2017-05-03 08:54:31 +1000, Cameron Simpson wrote: > On 03May2017 08:52, Cameron Simpson <c...@zip.com.au> wrote: > > If you know it will be interactive you need to arrange that specially. > > In particular, you possibly want to make the shell or command the > > process group leader and set that group as the controlling terminal's > > group, as that affects the handling of signals. > > Just to this, possibly emacs needs to be arranging this.
Yes, but this is just a workaround, and I had reported a bug against Emacs for that, which was eventually solved: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11886 Indeed, the problem is no longer reproducible. But there's the same problem with Mutt! For instance, mutt -F /dev/null then type Ctrl-C, n (i.e. do not exit yet), x (to exit). As expected, Mutt terminates with exit status 0 since the user has told Mutt to ignore the interrupt by answering 'n'. Now, try with dash: dash -c 'mutt -F /dev/null' then type Ctrl-C, n (i.e. do not exit yet), x (to exit). Here, dash terminates with a nonzero exit status: 130 (for SIGINT). Would you regard this as a bug in Mutt? IMHO, it would be tedious if any (interactive or not) command that catches SIGINT would have to make itself as a process group leader. This would be even more complex for commands that do not catch SIGINT permanently (e.g. catch SIGINT only during critical parts, but make SIGINT behave as usual otherwise, as if the command were not a process group leader). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
