On 02May2017 10:43, vincent lefevre <vinc...@vinc17.org> wrote:
[...] And I compiled Mutt with EXECSHELL set to
a wrapper to /bin/bash (not /bin/sh since this is dash in general
and dash is broken[*]) [...]
[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683671
I'm not sure this is a bug in dash, but a misfeature in bash.
Anyway, the justification cited in the bug:
And indeed, the system(3) man page says:
system() executes a command specified in command by calling
/bin/sh -c command, and returns after the command has been
completed. During execution of the command, SIGCHLD will be
blocked, and SIGINT and SIGQUIT will be ignored.
pretty clearly implies that _system()_ makes these signal arrangements, not the
invoked shell i.e. shuffile signals, fork/exec, unshuffle signals.
Invoking a command vi -c is not normally very different to running a script;
when you type ^C you expect everything to stop. Dash or bash have no way to
know that the subcommands are interactive.
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.
This is all really an argument that mutt (or you) should be arranging this
situation if it is invoking something interactive.
To my eye dash is behaving reasonably.
Cheers,
Cameron Simpson <c...@zip.com.au>
