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

[Keith Thompson]

On Tue, Nov 10, 2015 at 12:56 PM, Chet Ramey <chet.ramey@case.edu> wrote:

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?

It looks like it does it for all interactive shells.  For all 4 combinations

(rxvt vs. rxvt -ls, xterm --norc vs. xterm --norc --login),

Ctrl-Z doesn't work.

 

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.

Thanks, I'll pass this information on to the rxvt and urxvt maintainers. 

--

Keith Thompson <Keith.S.Thompson@gmail.com>