Problems on Linux with Ctrl-D and Ctrl-C during raw_input

[Rebecca]

BPO	1195
Nosy	@birkenfeld, @pitrou, @vstinner, @devdanzin
Files	clear_eof.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-05-30.21:51:50.472>
created_at = <Date 2007-09-24.10:48:56.065>
labels = ['type-bug', 'library']
title = 'Problems on Linux with Ctrl-D and Ctrl-C during raw_input'
updated_at = <Date 2011-05-30.21:51:50.470>
user = 'https://bugs.python.org/Rebecca'

bugs.python.org fields:

activity = <Date 2011-05-30.21:51:50.470>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2011-05-30.21:51:50.472>
closer = 'vstinner'
components = ['Library (Lib)']
creation = <Date 2007-09-24.10:48:56.065>
creator = 'Rebecca'
dependencies = []
files = ['21949']
hgrepos = []
issue_num = 1195
keywords = ['patch']
message_count = 17.0
messages = ['56109', '56112', '59242', '87647', '116777', '120899', '131280', '131323', '135659', '135660', '135661', '135671', '135672', '135693', '137335', '137336', '137337']
nosy_count = 10.0
nosy_names = ['georg.brandl', 'pitrou', 'falsetru', 'vstinner', 'ajaksu2', 'schmir', 'Rebecca', 'nvetoshkin', 'Finkregh', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'patch review'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1195'
versions = ['Python 3.1', 'Python 2.7', 'Python 3.2', 'Python 3.3']

[Rebecca]

Run the program:

while True:
    try:
        s = raw_input('> ')
    except:
        pass

Press Ctrl-D and then Ctrl-C, and you get

Traceback (most recent call last):
  File "test.py", line 5, in ?
    s = raw_input('> ')
KeyboardInterrupt

Pressing just Ctrl-D or Ctrl-C continues the loop as expected, Ctrl-D
after Ctrl-C works, too. Only Ctrl-C after Ctrl-D sucks, even when you
try to catch "EOFError" and "KeybordInterrupt" explicitly.

The problem occurs with Python 2.4 and 2.5 on Debian testing, friends
confirmed the error under Ubuntu/2.5 and Gentoo/?.

The error does not occur when you import readline first.

Ah, and by the way: http://docs.python.org/lib/reporting-bugs.html
still links to the sourceforce bucktracker.

[birkenfeld]

There are a few other issues about raw_input and signals in the tracker,
possibly this is just another incarnation...

The docs tracker link is fixed, but needs a rebuild on the server.

[schmir]

The following patch fixes it. The end-of-file indicator is still set,
fgets returns NULL when ctrl-c is pressed, and the code checks for
feof(fp) which is true. PyErr_CheckSignals() isn't called.
This patch calls clearerr on the filepointer and consequently after
ctrl-c feof(fp) is false and PyErr_CheckSignals is called.

What I don't understand is why the backtrace says the KeyboardInterrupt
happens in raw_input. PyErr_CheckSignals must be called on the "pass"
statement otherwise something would be fundamentally broken (But I guess
then python somehow saves the last real bytecode command).

~/Python-2.5.1/ hg diff  
diff --git a/Parser/myreadline.c b/Parser/myreadline.c
--- a/Parser/myreadline.c
+++ b/Parser/myreadline.c
@@ -44,6 +44,7 @@ my_fgets(char *buf, int len, FILE *fp)
                if (PyOS_InputHook != NULL)
                        (void)(PyOS_InputHook)();
                errno = 0;
+               clearerr(fp);
                p = fgets(buf, len, fp);
                if (p != NULL)
                        return 0; /* No error */

[devdanzin]

Confirmed in trunk, doesn't seem to affect py3k.

[BreamoreBoy]

There's a one line patch in msg59242, could someone please take a look. Apparantly py3k is not affected by this issue although I haven't tried it myself.

[nvetoshkin]

Confirming that issue is present in latest svn checkout and Ralf's fix helps.

[nvetoshkin]

up!

[vstinner]

Instead of always calling clearerr(), we can only call it on EOF:

diff -r 88fe1ac48460 Parser/myreadline.c
--- a/Parser/myreadline.c       Mon Mar 07 08:31:52 2011 +0100
+++ b/Parser/myreadline.c       Fri Mar 18 10:57:23 2011 +0100
@@ -72,6 +72,7 @@
     }
 #endif /* MS_WINDOWS */
     if (feof(fp)) {
+        clearerr(fp);
         return -1; /* EOF */
     }
 #ifdef EINTR

This patch works around this issue.

[python-dev]

New changeset fa3227c3cf87 by Victor Stinner in branch '3.1':
Issue bpo-1195: Fix input() if it is interrupted by CTRL+d and then CTRL+c,
http://hg.python.org/cpython/rev/fa3227c3cf87

New changeset b5914bfb4d04 by Victor Stinner in branch '3.2':
Issue bpo-1195: Fix input() if it is interrupted by CTRL+d and then CTRL+c, clear
http://hg.python.org/cpython/rev/b5914bfb4d04

New changeset 3ff5d28ab630 by Victor Stinner in branch 'default':
(Merge 3.2) Issue bpo-1195: Fix input() if it is interrupted by CTRL+d and then
http://hg.python.org/cpython/rev/3ff5d28ab630

[python-dev]

New changeset c9f07c69b138 by Victor Stinner in branch '2.7':
(Merge 3.1) Issue bpo-1195: Fix input() if it is interrupted by CTRL+d and then
http://hg.python.org/cpython/rev/c9f07c69b138

[vstinner]

It should be fixed. Reopen the issue if it doesn't work, I only tested on Linux.

[schmir]

The patch still does not handle the case where the eof indicator is already set when calling raw_input. My original patch does.

Run the following program and hit ctrl-d, then ctrl-c:

import sys
sys.stdin.read()

while True:
    try:
        s = raw_input('> ')
    except:
        pass