Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Chet Ramey]

On 11/10/15 3:17 PM, Keith Thompson wrote:
> On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey <chet.ramey@case.edu
> <mailto:chet.ramey@case.edu>> wrote:
> 
> 
> 
>     It seems like you need to figure out why rxvt starts the shell with
>     SIGTSTP ignored.  It doesn't seem like anything that the system /bin/sh
>     or the bash version you're running does, since xterm doesn't exhibit
>     this behavior.
> 
>     The difference between bash-4.3 and bash-4.4 is a bug fix: if the shell
>     is started with SIGTSTP ignored (any signal, really), it's supposed to
>     pass that setting on to the children it invokes.  bash-4.3 didn't do that
>     in this case, and bash-4.4 does.
> 
> 
> And I think I've found it.  In rxvt 2.6.4, src/command.c:
> 
>      /*
>      * mimick login's behavior by disabling the job control signals
>      * a shell that wants them can turn them back on
>      */
> #ifdef SIGTSTP
>     signal(SIGTSTP, SIG_IGN);
>     signal(SIGTTIN, SIG_IGN);
>     signal(SIGTTOU, SIG_IGN);
> #endif              /* SIGTSTP */
> 
> The latest release, rxvt 2.7.10, has the same code in src/init.c.
> rxvt-unicode (urxvt) has the same code in src/init.C.

Does it do this only when it's starting a login shell?  Or all interactive
shells?

See, the problem is not the behavior of the shell rxvt starts.  It's that
shells are supposed to restore the original signal dispositions when they
create processes.  A shell that has SIGTSTP ignored when it starts is
permitted to change the disposition to whatever it wants (though the user
can't set a trap on it), but is supposed to restore the original signal
handler (SIG_IGN in this case) in child processes it forks to run other
programs.

> Would you consider this a bug in rxvt? It's obviously intentional, but I
> don't understand signal handling well enough to know whether it's reasonable.
> The comment implies that it's the shell's responsibility to re-enable the
> signals -- which bash did prior to 4.4-beta, but no longer does.

That's not quite it, see above.

> There's certainly a bug *somewhere*, since anyone using bash 4.4-beta or later
> under rxvt or urxvt won't be able to use Ctrl-Z.  If it's rxvt that's
> buggy, I'll
> contact the rxvt and urxvt maintainers (and I'll probably recompile my own
> version with those lines commented out).

You might ask them to reconsider that decision.  What's the concern, that
a non-job-control shell will suspend itself when someone hits ^Z?

I can make bash blow away the original signal dispositions and pretend they
were SIG_DFL when an interactive shell starts, if there is no alternative.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/