This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: fix bug #685846: raw_input defers signals
Type: behavior Stage: test needed
Components: Interpreter Core Versions: Python 3.1, Python 3.2, Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, ajaksu2, amaury.forgeotdarc, georg.brandl, mbrierst, ned.deily, ysj.ray
Priority: normal Keywords: patch

Created on 2003-03-19 17:46 by mbrierst, last changed 2022-04-10 16:07 by admin. This issue is now closed.

File name Uploaded Description Edit
patchrawinput.diff mbrierst, 2003-03-19 17:47 ajaksu2, 2009-05-12 18:36 Test script merging those of the superseded issues
Messages (11)
msg43054 - (view) Author: Michael Stone (mbrierst) Date: 2003-03-19 17:46
This patch attempts to fix raw_input so it
can be interrupted by signals.  In the process
it allows SIGINT handling to be honored by
raw_input.  (right now SIGINT always interrupts
regardless of any installed handlers)

Signals are handled with their installed handlers
and when those handlers raise exceptions those
exceptions are raised by raw_input.  If an
exception is not raised, raw_input continues
collecting input as if nothing had happened.
This can be problematic if the signal causes
output to appear on the screen, messing up
the input line, or if someone using the
readline module was in the middle of a
complex operation, like a reverse search,
in which case that operation will be
cancelled.  It would be easy to instead
print a message ("Signal Interruption")
and continue input on a new line for the
readline library, but this couldn't happen
in myreadline.c as we can't retrieve the
partially entered input.

Backwards compatibility:
This patch requires the readline handler
(either call_readline or PyOS_StdioReadline
generally) to be called while holding the
global interpreter lock.  It is then
responsible for releasing the GIL before doing
blocking input. This will cause problems
for anyone who has written an extension
that installs a custom readline handler.
In python code, anyone using signals and
expecting raw_input not to be interrupted
by them will have problems (but this seems
msg55698 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-09-06 15:13
Set as superseder of #685846 and #1113.
msg87650 - (view) Author: Michael Stone (mbrierst) Date: 2009-05-12 18:29
ajaksu2 has uploaded a file called "" that seems to have nothing 
to do with this issue, unless I'm misunderstanding something.  I don't 
see any call to readline in the uploaded file at all.  Perhaps the file 
you meant to upload, was the one from issue 1113?
msg87652 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-05-12 18:36
Oops, sorry! I should know better than to name scripts the
upload failed and when I realized that (after some time), was
already something else.

Thanks for catching this instance of PEBKAC, Michael :)
msg114227 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-18 14:44
Can this still be reproduced on an appropriate box or can it be closed or what?
msg114229 - (view) Author: ysj.ray (ysj.ray) Date: 2010-08-18 15:09
I seems this has been fixed already, at least on my python 2.7 on linux.
msg114316 - (view) Author: Michael Stone (mbrierst) Date: 2010-08-19 01:07
Wow, you wait 3/4 of a decade or so and the status of these bugs does tend to change on you.  I'm not sure it's fixed, but it is different.  Here's a test script for you:

import readline
import signal
def handle(a,b):
   print "received signal"
signal.signal(signal.SIGALRM, handle)
name = raw_input('Please enter your name within 5 seconds: ')
print name

The behavior of this script as is, since at least python 2.5 or so, is after 5 seconds to run the signal handler and then keep waiting for input (assuming you've got readline on your box of course).  I like this behavior, everything seems good to me so far.

Now comment out the "import readline", and suddenly you're getting an EOFError after the signal handler runs normally.  Still better than it used to be in 2003, but I'm not sure if this inconsistency is okay or not.

Now let's throw another wrench in the system.  Raise an exception in the signal handler.  Suddenly both are consistent again with and without readline, both raising the exception from the signal handler.  Sounds good to me.

So I guess someone has to decide, is this EOFError a new bug?  Or is this inconsistency acceptable and/or too hard to fix?  I haven't looked at the code in forever, so I can't speak for how hard it would be to fix.
msg116636 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-16 23:01
Can someone please comment on msg114316 as I'm out of my depth here, thanks.
msg122050 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2010-11-22 00:43
(Noted in passing: Issue9867 may be relevant here.)
msg190038 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2013-05-26 00:19
Bump this as IIRC other issues discussing SIGINT handling have been processed recently.
msg190114 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2013-05-26 20:56
Closing as fixed. I tested with python2.7 and 3.2, both with and without a readline module.

Behavior is consistent and looks correct to me: the signal is honored (message printed after 5s), and does not stop the raw_input(), except when it raises an exception, in which case the command exits and the exception is propagated.
Date User Action Args
2022-04-10 16:07:46adminsetgithub: 38182
2013-05-26 20:56:07amaury.forgeotdarcsetstatus: open -> closed

nosy: + amaury.forgeotdarc
messages: + msg190114

resolution: out of date
2013-05-26 00:19:14BreamoreBoysetnosy: + BreamoreBoy
messages: + msg190038
2010-11-22 00:43:56ned.deilysetnosy: + ned.deily, - BreamoreBoy
messages: + msg122050
2010-09-16 23:01:16BreamoreBoysetmessages: + msg116636
versions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6
2010-08-19 01:07:23mbrierstsetmessages: + msg114316
2010-08-18 15:09:39ysj.raysetnosy: + ysj.ray
messages: + msg114229
2010-08-18 14:44:47BreamoreBoysetnosy: + BreamoreBoy
messages: + msg114227
2009-05-12 18:36:14ajaksu2setfiles: +

messages: + msg87652
2009-05-12 18:33:41ajaksu2setfiles: -
2009-05-12 18:29:38mbrierstsetnosy: + ajaksu2
2009-05-12 18:29:08mbrierstsetmessages: + msg87650
2009-05-12 18:04:59ajaksu2setfiles: +
stage: test needed
type: behavior
versions: + Python 2.6
2007-09-06 15:14:16georg.brandllinkissue1113 superseder
2007-09-06 15:13:48georg.brandlsetnosy: + georg.brandl
messages: + msg55698
2007-09-06 15:13:23georg.brandllinkissue685846 superseder
2003-03-19 17:46:15mbrierstcreate