On Tue, Nov 10, 2015 at 12:56 PM, Chet Ramey <chet.ra...@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.ra...@case.edu > > <mailto:chet.ra...@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.thomp...@gmail.com>
