[Techtalk] Ctrl-C handling and stty
mim at miriam-english.org
Wed Aug 27 06:51:03 UTC 2014
I tend to use wget and wput a lot for their ease of scripting even
though they miss out on a lot of the things a dedicated ftp program has.
lftp looks pretty amazing. I hadn't heard of it before you mentioned it.
Thank you for the pointer.
On 27/08/14 11:39, Akkana Peck wrote:
> Interesting -- I hadn't tried under any other shells. Though I did
> notice that the first ^Z doesn't do anything: under zsh, at least,
> if I ncftp somewhere and ^Z, my shell function doesn't fire to tell
> me the stty settings have changed ... but if I fg, then ^Z again,
> now the stty settings have changed and my shell function alerts me.
> It may be something like ncftp getting confused about where it gets
> the saved settings it uses to restore the tty on ^Z or exit.
> And you're right about bash vs. zsh, too -- it looks like it doesn't
> happen under bash. Wow, that's even stranger!
> When I exit ncftp with ^C, I get "Interrupted." rather than "Thank
> you for using NcFTP Client", under either bash or zsh. But that may
> just be a difference in ncftp version -- I have 3.2.5 (which alas
> means that installing a newer version probably won't help anything).
> I do get the "Thank you" message when I exit normally with ^D.
> All very puzzling!
> I did find out what the stty difference was. I stumbled on a page
> suggesting using "stty sane" instead of reset for borked terminals,
> and stty sane did indeed fix things, and without the screen-clearing
> side effect of reset. The man page explains what settings stty sane
> changes, so I tried them in small batches and eventually narrowed it
> down to isig. So stty isig brings back the proper ^C handling.
> I still don't understand why that didn't show up as different when
> I ran meld on the before and after stty -a outputs.
> I'm probably going to be using lftp. ncftp wasn't all that great
> anyway -- it has no recursive/mirror mode, which lftp has,
> and maybe lftp has a way (ncftp doesn't) to copy files in multiple
> directories at once. It got really tiresome in ncftp needing to do
> things like
> put *.php
> lcd ../otherdir
> cd ../otherdir
> put *.php
> lcd ../resources/birds
> cd ../resources/birds
> put ... and so on, for each directory where there were changed files.
> lftp seems more scriptable/configurable, so maybe being forced off
> ncftp by the suspend/tty bug will turn out to be a blessing in disguise.
> Miriam English writes:
>> It looks like ncftp changes how the terminal responds to SIGINT so that when
>> you exit unexpectedly from ncftp it leaves the terminal set up wrongly --
>> ncftp didn't restore the terminal settings.
>> I tried installing ncftp 3.2.2 and ^C works fine inside it. When I ^Z out of
>> it ^C continues to work fine in the terminal. I use rxvt and my shell is
>> bash (I don't have zsh).
>> So I installed zsh and ncftp still behaves properly. I notice that when I
>> exit with ^C under zsh ncftp prints up a cute message "Thank you for using
>> NcFTP Client" which I guess means it is trapping the ^C from the terminal
>> instead of just getting killed. That's interesting.
>> Next I tried running ncftp under zsh and killing the process from another
>> window. Ah, yes! Now the terminal has dropped back to the prompt, but no
>> longer responds to ^C. (Puzzlingly, if I do the same thing, but under bash
>> ^C continues to work fine.)
>> Maybe your version of ncftp is an older one for which there is a newer
>> bug-fix. It would save having to relearn another program. :)
>> Good luck,
>> - Miriam
>> On 27/08/14 03:35, Akkana Peck wrote:
>>> 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:
>>> stty -a | fgrep -- -ignbrk > /dev/null
>>> if [ $? -ne 0 ]; then
>>> echo "STTY SETTINGS HAVE CHANGED \!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!"
>>> 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.
>>> Techtalk mailing list
>>> Techtalk at linuxchix.org
>> If you don't have any failures then you're not trying hard enough.
>> - Dr. Charles Elachi, director of NASA's Jet Propulsion Laboratory
>> Website: http://miriam-english.org
>> Blogs: http://miriam-e.dreamwidth.org
If you don't have any failures then you're not trying hard enough.
- Dr. Charles Elachi, director of NASA's Jet Propulsion Laboratory
More information about the Techtalk