#3595: problems suspending mutt when called from shell script
---------------------------+----------------------
  Reporter:  blmassingill  |      Owner:  mutt-dev
      Type:  defect        |     Status:  new
  Priority:  minor         |  Milestone:
 Component:  mutt          |    Version:  1.5.21
Resolution:                |   Keywords:
---------------------------+----------------------

Comment (by blmassingill):

 Replying to [comment:1 zsdzsd]:
 > Are you sure it works in 1.4.2?  I tried compiling 1.4.2.3 and I still
 > get the same problem.



 Yes -- but what I'm using is a slightly earlier version.  First line of
 output of "mutt -v" is

 Mutt 1.4.2.1i (2004-02-12)




 >
 > The problem, which shows up in programs such as grepm (I add that
 > mainly for people searching the bug list), may be related to
 > the following code in signal.c:
 > {{{
 > RETSIGTYPE sighandler (int sig)
 > {
 >   int save_errno = errno;
 >   struct sigaction act;
 >
 >   switch (sig)
 >   {
 >     case SIGTSTP: /* user requested a suspend */
 >       if (!option (OPTSUSPEND))
 >         break;
 >       IsEndwin = isendwin ();
 >       curs_set (1);
 >       if (!IsEndwin)
 >         endwin ();
 >       kill (0, SIGSTOP);
 > }}}
 > This codes assumes that a SIGSTOP is just as good as a SIGTSTP, but
 > (perhaps) when mutt is running inside a subshell (a la) grepm, the two
 > signals are not handled analogously.  Or perhaps the issue is as I
 > speculate below (*).
 >
 >
 > I tried making the following change to signal.c in 1.4.2.3:
 > {{{
 > RETSIGTYPE sighandler (int sig)
 > {
 >   int save_errno = errno;
 >   sigset_t mask;                                      /* NEW */
 >   struct sigaction act;
 >
 >   switch (sig)
 >   {
 >     case SIGTSTP: /* user requested a suspend */
 >       if (!option (OPTSUSPEND))
 >         break;
 >       IsEndwin = isendwin ();
 >       curs_set (1);
 >       if (!IsEndwin)
 >         endwin ();
 >       /* OLD kill (0, SIGSTOP); */
 >       /* REST OF THIS TO "HERE" IS NEW: */
 >       sigemptyset(&mask);
 >       sigaddset(&mask, SIGTSTP);
 >       sigprocmask(SIG_UNBLOCK, &mask, NULL);
 >       signal(SIGTSTP, SIG_DFL);   /* reset disposition to default */
 >       sigemptyset(&act.sa_mask);
 >       sigaddset(&act.sa_mask, SIGTSTP);
 >       act.sa_flags = 0;
 >       act.sa_handler = sighandler;
 >       kill(0, SIGTSTP);
 >       /* wait to be CONTinued... */
 >       sigprocmask(SIG_BLOCK, &mask, NULL); /* DO I WANT THIS?? */
 >       sigaction(SIGTSTP, &act, NULL);
 >       /* HERE */
 > }}}
 >
 > and the situation is much improved, but (annoyingly) there is the
 > occasional situation in which the problem occurs.  (See (*) below.)
 >
 >
 > I tried replacing
 > {{{
 >     kill(0, SIGTSTP);
 > }}}
 > with
 > {{{
 >     kill(getpid(), SIGTSTP);
 > }}}
 > and that didn't work any better.  (The thought being that the subshell
 which called mutt has
 > already received SIGSTSP, so it doesn't need another signal.)
 >
 > (*) I speculate that there is some race condition between when mutt
 > and the subshell process the SIGTSTP.  But even if this is true, I'm
 > not immediately sure how to deal with this.
 >
 > Are there any signal handling / process groups / terminal emulator
 > wizards here who could comment?
 >

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3595#comment:3>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

Reply via email to