Control: found -1 2.16.13
Control: found -1 2.17.0
On 2017-01-11 19:23:38 +1100, Ben Finney wrote:
> This does not happen for me when I try (using ‘devscripts/2.16.13’).
Note that the problem does not always occur. But when it occurs,
in general, Mutt no longer gets the keys from the keyboard.
> The ‘fg’ command simply resumes the MUA (in my case, ‘mutt’) as expected.
I also use mutt.
> Can you try reproducing this:
>
> * With the current ‘devscripts’ version?
Same problem with 2.16.13 and 2.17.0.
> * Using each of Zsh and Bash?
Same problem from bash and zsh.
I've also tried from dash, but after Ctrl-Z, dash no longer receives
any key from the keyboard.
> * Using a different MUA?
No problems if I use:
bts show --mailreader="less %s" --mbox 622231
or
bts show --mailreader="lynx -force_html %s" --mbox 622231
Something interesting: when I type Ctrl-Z after running Mutt, zsh
mentions a STOP signal instead of the usual TSTP. This is due to:
case SIGTSTP: /* user requested a suspend */
if (!option (OPTSUSPEND))
break;
IsEndwin = isendwin ();
curs_set (1);
if (!IsEndwin)
endwin ();
kill (0, SIGSTOP);
But lynx also needs to restore the terminal state, and zsh shows
TSTP, though lynx has:
kill(getpid(), SIGSTOP);
Well, this may not matter. But I wonder whether the "kill (0, SIGSTOP);"
(i.e. SIGSTOP sent to the progress group) is the problem with Mutt.
Doesn't this mean that the parent processes "sh" and "perl bts",
which don't trap SIGTSTP, can get stopped twice? Since Mutt is
presumably the only process to trap SIGTSTP, it should use getpid()
like lynx, IMHO. Now, I've rebuilt mutt with getpid() instead of 0,
and this doesn't make the problem disappear.
--
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)
