On Mon, Feb 02, 2026 at 15:17:31 -0700, Stan Marsh wrote: > From: Chet Ramey > >Bash saves the tty state before each foreground command, and restores the > >saved tty settings if the command stops or terminates due to a signal. > >Otherwise, the shell has to provide a builtin that mimics some or all of > >`stty'. > > I'm never quite sure what your posts mean, since you are, shall we > say, (more than) a bit laconic.
The important part here is "due to a signal". Imagine you run a command like "stty" which alters the terminal state (intentionally). You wouldn't want bash to undo this. So, if stty exits in a normal manner, the terminal changes are retained. > But for whatever it is worth, it is true that from time to time, I > find myself in bash having to blind-type "stty sane^j" because some > program has crashed out without fixing the terminal modes. This never > happens in tcsh. I don't use tcsh, so I'm curious how tcsh interacts with the stty command. Is "stty" hard-coded as an exception, which will cause tcsh not to restore the terminal state afterward? > I can't say for sure when/how this happens, but it does. In fact, > there is a program that I wrote (a long time ago) (and still use > today) that puts the terminal into no-echo mode and, of course, resets > the mode on a normal exit, but if it crashes out (which can happen), > sometimes, in bash, it leaves the echo off. A "crash" is indistinguishable from a normal exit, from the shell's point of view, unless the "crash" is the result of a signal. In the ideal case, a program that alters the terminal state will set up an "atexit" hook or a signal handler to restore the terminal state before exiting. Of course, this won't work if the program is killed by SIGKILL, but there's nothing you can do about that except to educate users not to use kill -9.
