[Techtalk] Ctrl-C handling and stty

[Akkana Peck]

Miriam English writes:
> On Linux (with a relatively recent kernel), you can tell if a process is
> ignoring and/or handling SIGINT by looking at the output of
> 
>   $ kill -l INT

That's fun to know -- I didn't know about kill -l.

But the issue here isn't a running process ignoring SIGINT -- it's
that the terminal is messed up so that Ctrl-C isn't sending SIGING
anywhere, not even in the shell.  (Normally, if you type Ctrl-C at a
prompt, it sends a SIGINT to the shell and the shell prints another
prompt, but in this mode it does nothing at all.)

>   $ stty -a < /dev/pts/0
>   [...] intr = ^C [...] isig

stty -a is what I was doing -- intr was still ^C but a few other
settings were changed, so I was running stty -ignbrk -ignpar iexten ixon
to set them back to (seemingly) what they were before, but it didn't
restore normal Ctrl-C handling. There's something else that stty -a
isn't showing, apparently, that's blocking interrupts from being sent.

I did find out what's putting me into the weird mode: it's when
I suspend out of ncftp with ^Z. I found out by defining this function
(in zsh) to check the output of stty -a before printing each prompt:

precmd()
{
    stty -a | fgrep -- -ignbrk > /dev/null
    if [ $? -ne 0 ]; then
        echo
        echo "STTY SETTINGS HAVE CHANGED \!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!"
        echo
    fi
}

That doesn't solve the problem of what's wrong with the terminal,
but at least it tells me how to reproduce it, and how to get warning
when it happens. And meanwhile I guess it tells me I need to learn to
use lftp instead of ncftp.

        ...Akkana