Our machines at work run RHEL and default to ksh which while workable is not my prefered shell. However, when I use chsh to change my default shell to bash I get a behavior I have never experinced.

When you login with the adjusted settings bash no longer captures the control-c, but instead passes it directly to the system which exits the bash session instead of the more usual behavior where bash drops the current line and returns to a new prompt.

Now, if you change the default shell back to ksh and login then start a new bash session everything works fine, so I am working under the assumption that a Enviroment or sh variable is not being set correctly when bash is the default shell. Possibly a profile script being skipped.

Does anyone know what specific variable might be missing so I can add it to .bashrc or .bash_profile

The problem is not that bash is passing the key to the system, but that the system is not passing the key to bash. The keyboard driver, which first handles the keystrokes, is what translates some of them into signals sent to the process (in this case, ^C produces a sigterm). Bash uses library functions to change the keyboard driver's settings. One of the variables described in http://www.gnu.org/software/bash/man...Bash-Variables may cause bash to change this.

Ok, this took me a while. One of the systems profiles was changing the trap settings. I thought it was a stty setting that would of done this. Thanks for the documentation. I had been searching for solutions using the wrong symptoms and keywords. Like you said by default bash should just ignore SIGINT, so the problem was that a trap for SIGINT had been set and not that it wasn't trapping it at all.

grep trap /etc/profile*
/etc/profile:trap "exit" 1 2 3 9 15
/etc/profile.bak:trap "exit" 1 2 3 9 15