Control-C on Unix misbehaviour?
Michael Hudson
mwh21 at cam.ac.uk
Mon Oct 18 08:22:47 EDT 1999
"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
More information about the Python-list
mailing list