On Tue, May 24, 2011 at 5:29 PM, Andy Wilkinson <drukar...@gmail.com> wrote: > On 05/24/2011 12:38 PM, Todd Goodman wrote: >> >> * Andy Wilkinson<drukar...@gmail.com> [110524 12:24]: >>> >>> I can't say for sure when this started, as I have gone a while without >>> accessing my computer remotely much, but perhaps since my last upgrade >>> (which may have included openrc), ctrl-c doesn't work over ssh. I have >>> tested this from multiple workstations and even my droid, using >>> different terminal emulators, and have got consistent results. >>> >>> I'm not even sure where to start looking. Googling didn't find me much >>> (at least, not much that's current at all; 5 year-old ubuntu bugs aren't >>> very useful), and I'm not sure at all what might be causing this. Could >>> anyone here point me to something that might be causing this? >>> >>> Thanks, >>> >>> -Andy >> >> I don't have any problems. What does 'stty -a' show for the intr= bit? >> >> Todd >> > $ stty -a > speed 38400 baud; rows 23; columns 80; line = 0; > intr = ^C; ... > > Which looks right, but when I try to use Ctrl-C, this happens: > > $ ping localhost > PING localhost (127.0.0.1) 56(84) bytes of data. > 64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.037 ms > ^C64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.032 ms > ^C^C^C64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.032 ms > ^C^C^C^C^C^C64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 > time=0.034 ms > ^C^C^C^C^C^C64 bytes from localhost (127.0.0.1): icmp_req=5 ttl=64 > time=0.032 ms > ^Z > > This does NOT happen locally: from a console or terminal at the machine, I > can interrupt just fine. Ctrl-Z does//work over ssh.
That's so strange... I'm curious, if you open another terminal and issue SIGINT to that process (using kill), does it work? I think it should be the equivalent to hitting ctrl-c interactively. "trap" command can be used in scripts to block certain signals... I wonder if your profile/bashrc/or something has a trap entry. But if that's the case I would guess that the same problem would happen locally, and not only remotely (unless remote session uses a different shell or something). Just a W.A.G. :)
