Description of problem: This weird problem started happening with 3.0-38 and is still in 3.0-40 : When sent the SIGHUP signal, bash does not exit until another command is typed and return is pressed. This prevents xterm running a bash process from exiting, as it sends its child bash process a SIGHUP signal, and then waits for the SIGCHLD from the exited child before exiting . When the bash child process has been sent a SIGHUP, only when an actual command is typed and return is pressed does bash actually exit . Also typing 'kill -HUP $$' in the bash child does make it exit correctly. Version-Release number of selected component (if applicable): 3.0-38 to 3.0-40.1 How reproducible: 100% Steps to Reproduce: 1. start xterm with your $SHELL set to bash 2. try to click on the X/Exit button of the window manager frame 3. xterm (bash) does not exit 4. Press return - xterm (bash) does not exit 5. type any command or statement - eg. 'ls', 'echo $$' - then press return and bash & xterm exits. The same behaviour occurs if the bash child process is set a HUP signal from the root user, not xterm - it waits for the next command before exiting. Additional Information: At first I thought this was an xterm problem, but running eg. $ SHELL=ksh xterm there are no such problems with xterm exiting.
Wow...I spent hours trying to find the problem with KDE konsole, which does the same behavior and more (it thinks an application in running even though non is and when you say close it does not, until you type in a command and boom). Using ksh like you have does not have the problem. I hope there is a resolution soon. Thanks
Thanks for the report. Should be fixed in bash-3.0-41 in tomorrow's rawhide (or check out and build current CVS).
Yes, bash-3.0-41 fixes the problem - thanks!