Control-C on Unix misbehaviour?

[Michael Hudson]

"Tim Peters" <tim_one at email.msn.com> writes:
> [Michael Hudson]
> > Something I noticed but never got around to moaning about around the
> > time of the transition from 1.5.1 to 1.5.2 was that now hitting Ctrl-C
> > at the interpreter prompt tends to dump me out to the shell.
> 
> "Tends"?  I hope you can make a bolder claim than that <wink>.

OK: It's readline's fault.

If I execute:

[mwh21 at atrus src]$ python -c "raw_input()"

then type f, f, control-c, control-c (that wierdness I'm used to) I
get:

ffTraceback (innermost last):
  File "<string>", line 1, in ?
KeyboardInterrupt

However, if I try 

[mwh21 at atrus src]$ python -c "import readline; raw_input()"

and hit f, f, and then just one control-c, I get just:

ff

and then I'm back to the bash prompt.
 
> If Ctrl-C does kill the interpreter, it's a platform-specific bug.  Start
> your exciting search by trying:
> 
> >>> import signal
> >>> signal.default_int_handler()
> 
> Hoping for something like:
> 
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> KeyboardInterrupt
> >>>
> 
> and still in the interpreter shell.

No, that all works. The execution is never getting to the handler. I
can do this:

>>> import signal
>>> def f():
...  print "hello"
...
>>> signal.signal(signal.SIGINT,f)
<built-in function default_int_handler>
>>> ^C - and back we go to bash

I get the same behaviour if I use `kill' from another xterm, so it
looks as if the signal's getting deleivered correctly.

possibly relavent info:

python 1.5.2 (both from redhat 6.1 & a fairly recent cvs)
readline-2.2.1-5 (according rpm -q readline)

running under gdb yields different behaviour (oh good!) - hitting
control-C drops you into __libc_read where the stack looks a bit like
this:

#0  0x40113db4 in __libc_read () from /lib/libc.so.6
#1  0x40052a7c in __DTOR_END__ () from /lib/libpthread.so.0
#2  0x4002f422 in rl_getc () from /usr/lib/libreadline.so.3
#3  0x4002f3e2 in rl_read_key () from /usr/lib/libreadline.so.3
#4  0x40021aa5 in readline_internal_char () from /usr/lib/libreadline.so.3
#5  0x40021b7b in readline_internal_charloop () from /usr/lib/libreadline.so.3
#6  0x40021baa in readline_internal () from /usr/lib/libreadline.so.3
#7  0x40021888 in readline () from /usr/lib/libreadline.so.3
#8  0x8085d85 in call_readline (prompt=0x811be9c ">>> ") at ./readline.c:288
#9  0x8052689 in PyOS_Readline (prompt=0x811be9c ">>> ") at myreadline.c:148
#10 0x805184b in tok_nextc (tok=0x8140e70) at tokenizer.c:216
...

single stepping a few times through source-absent libc files leaves me
back at the Python interpreter's prompt.

Is that enough information to help anyone explain what's going on?
Anyone experience/not experience the phenomenon (I got one negative
via email).

> always-knew-the-bytecodehacks-would-kill-you<wink>-ly y'rs  - tim

Oh shut up <meta-double-wink-with-knobs-on/>.

not-quite-prepared-to-build-my-own-libc-and-readline-just-yet-ly y'rs
Michael