On 2017-05-03 08:52:26 +1000, Cameron Simpson wrote: > 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.
No, ksh93 behaves like 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. Not really. Well, with the POSIX spec of system(), this is clearer that this just applies to system(). *But* in the application usage for system(), the intent is that sh cooperates: Ignoring SIGINT and SIGQUIT in the parent process prevents coordination problems (two processes reading from the same terminal, for example) when the executed command ignores or catches one of the signals. If sh does not cooperate, the following can happen: both sh and the command receive SIGINT, where sh exits immediately but the command still runs (because it has trapped the signal). If the command is interactive, you'll get 2 processes reading the terminal at the same time: the parent process and the command. Under "application usage", POSIX also says: Applications that use system( ) in this way should carefully check the return status from system( ) to see if the executed command was successful, and should take appropriate action when the command fails. but with dash, this is not possible to know: even though the command (interactive or not) has returned with an exit status 0, dash itself may return with exit status 1 (this was the main problem concerning the use with Emacs). > Invoking a command vi -c is not normally very different to running a > script; ??? I don't know how vi behaves under all conditions. It seems to disable the intr character, which makes the problem go away, but this is not a solution for applications that need intr. > when you type ^C you expect everything to stop. No, not when SIGINT is trapped... like in Mutt, for instance. > Dash or bash have no way to know that the subcommands are > interactive. There is no relation with the fact subcommands are interactive. Whether a command is interactive or not, it may or may not trap SIGINT. The shell does not need to know. -- 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)
