[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Keith Thompson
Subject: Re: Bug in bash 4.4-beta: suspending and restarting "man" program
Date: Tue, 10 Nov 2015 13:09:39 -0800

On Tue, Nov 10, 2015 at 12:56 PM, Chet Ramey <address@hidden> wrote:
On 11/10/15 3:17 PM, Keith Thompson wrote:
> On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey <address@hidden
> <mailto:address@hidden>> 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

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

> 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 <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]