On Wed, Nov 11, 2015 at 11:55 AM, Chet Ramey <chet.ra...@case.edu> wrote:
> On 11/10/15 10:03 PM, Keith Thompson wrote: > > On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson < > keithsthomp...@gmail.com > > <mailto:keithsthomp...@gmail.com>> wrote: > > > > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab < > sch...@linux-m68k.org > > <mailto:sch...@linux-m68k.org>> wrote: > > > > Chet Ramey <chet.ra...@case.edu <mailto:chet.ra...@case.edu>> > writes: > > > > > 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. > > > > Given that login(1) has the same behaviour there is probably no > > alternative. > > > > Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and > > Ctrl-Z works correctly. > > I verified that the shell's parent process was "login". > > Perhaps (at least the Debian version of) login(1) *doesn't* do that. > > > > I'm going to hold off on contacting the rxvt and urxvt developers > > for now. If you decide to modify bash to blow away the original signal > > dispositions, there's no point in reporting this as a bug in rxvt. > > > > Does that make sense? > > Yeah, that's fine. I will modify bash to set the original signal > dispositions to SIG_DFL in interactive shells. > Does that mean reverting default_tty_job_signals() in jobs.h to the version in bash 4.3.30: set_signal_handler (SIGTSTP, SIG_DFL); set_signal_handler (SIGTTIN, SIG_DFL); set_signal_handler (SIGTTOU, SIG_DFL); or is there more to it than that? (I'd like to try out the change myself.) -- Keith Thompson <keith.s.thomp...@gmail.com>
