classification
Title: help crash leaves terminal in echo off mode
Type: behavior Stage: resolved
Components: IDLE Versions: Python 3.5, Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: RusiMody, berker.peksag, ezio.melotti, martin.panter, python-dev, r.david.murray, swanson
Priority: normal Keywords: patch

Created on 2015-03-27 17:09 by RusiMody, last changed 2015-07-17 14:03 by r.david.murray. This issue is now closed.

Files
File name Uploaded Description Edit
keyboardinterrupt_in_pydoc_pager.patch r.david.murray, 2015-03-27 19:08 review
keyboardinterrupt_in_pydoc_pager.patch r.david.murray, 2015-03-27 19:35 review
interrupt.patch martin.panter, 2015-03-29 23:47 review
catch_additional_interrupt.patch r.david.murray, 2015-03-30 00:15 review
Messages (20)
msg239417 - (view) Author: Rusi (RusiMody) Date: 2015-03-27 17:09
Start python3.4
Do help(something) which invokes the pager
Ctrl-C
A backtrace results and after that the terminal is in raw mode even after exiting python

[python 3.4 under debian testing with xfce4]
msg239420 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-27 17:37
I can't reproduce this.  Maybe it is a debian bug?
msg239422 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-03-27 17:50
This looks like a duplicate of issue 21398. I can reproduce it with Python 3.4.1 (compiled myself) on Ubuntu 12.04.

>>> help(str)

Ctrl-C

:Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.4/_sitebuiltins.py", line 103, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python3.4/pydoc.py", line 1817, in __call__
    self.help(request)
  File "/usr/local/lib/python3.4/pydoc.py", line 1867, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/usr/local/lib/python3.4/pydoc.py", line 1603, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/local/lib/python3.4/pydoc.py", line 1411, in pager
    pager(text)
  File "/usr/local/lib/python3.4/pydoc.py", line 1431, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/usr/local/lib/python3.4/pydoc.py", line 1453, in pipepager
    pipe.close()
  File "/usr/local/lib/python3.4/os.py", line 957, in close
    returncode = self._proc.wait()
  File "/usr/local/lib/python3.4/subprocess.py", line 1565, in wait
    (pid, sts) = self._try_wait(0)
  File "/usr/local/lib/python3.4/subprocess.py", line 1513, in _try_wait
    (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags)
  File "/usr/local/lib/python3.4/subprocess.py", line 491, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt
msg239423 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2015-03-27 17:50
I can reproduce on Python 3 on Ubuntu 14.10.
When I hit Ctrl+C I get:
>>> help(range)
...
 |  __hash__(self, /)
 |      Return hash(self).
 |  
:Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wolf/dev/py/py3k/Lib/_sitebuiltins.py", line 103, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1833, in __call__
    self.help(request)
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1886, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1619, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1409, in pager
    pager(text)
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1431, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1455, in pipepager
    pipe.write(text)
  File "/home/wolf/dev/py/py3k/Lib/subprocess.py", line 900, in __exit__
    self.wait()
  File "/home/wolf/dev/py/py3k/Lib/subprocess.py", line 1552, in wait
    (pid, sts) = self._try_wait(0)
  File "/home/wolf/dev/py/py3k/Lib/subprocess.py", line 1502, in _try_wait
    (pid, sts) = os.waitpid(self.pid, wait_flags)
KeyboardInterrupt
>>>

If I keep pressing Enter the rest of the help gets printed.  Once the pager is done, pressing enter doesn't go on a new line and the prompts (>>>) are printed one after the other on the same line.  The same happens on my shell prompt once I exit from the interpreter. `reset` fixes it.

On Python 2 Ctrl+C does nothing.
msg239426 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-27 18:25
I do see the anomalous behavior inside python, but on my gentoo system when I exit python the terminal is fine.
msg239427 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-27 19:08
The attached patch fixes the issue for me.
msg239428 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2015-03-27 19:11
Patch WFM too.
msg239429 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-27 19:19
The print of KeyboardInterrupt whould be dropped.  less itself does nothing if you press ctl-c, and the pager is used when pydoc is called from the shell command line, and printing KeyboardInterrupt there just looks wrong.
msg239431 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-27 19:35
Updated patch.
msg239446 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-03-28 00:44
I suspect you also need ignore signals while piping data to the child process. Similar to how the POSIX system() call ignores SIGINT and SIGQUIT soon after spawning the child, until after the child has exited.

Try with a large help text on Linux, like

import _pyio
help(_pyio)

Also, Python 2 still gets interrupted for me, it is just that it doesn’t seem to happen immediately if it is up to the pipe.close() call.
msg239460 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-28 16:59
SIGINT *is* keyboard interrupt.  Since less at least seems to ignore SIGQUIT I suppose also ignoring that would be reasonable, since the user (should) by analogy expect that behavior while the pager is active.  Note, however, that the signals we are ignoring are in the parent process, not the child as is the case for system.  So one can argue that letting the python process die when SIGQUIT is received would also be reasonable, and arguably is the less surprising option.
msg239511 - (view) Author: Roundup Robot (python-dev) Date: 2015-03-29 19:20
New changeset 77c04e949b4b by R David Murray in branch '3.4':
#23792: Ignore KeyboardInterrupt when the pydoc pager is active.
https://hg.python.org/cpython/rev/77c04e949b4b

New changeset fe0c830b43bb by R David Murray in branch 'default':
Merge: #23792: Ignore KeyboardInterrupt when the pydoc pager is active.
https://hg.python.org/cpython/rev/fe0c830b43bb
msg239512 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-29 19:21
I've committed the fix.  If someone wants to argue in favor of also handling SIGQUIT, they can open a new issue.
msg239535 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-03-29 23:47
I don’t think SIGQUIT handling is a big problem. But even with the new change, it is still easy to screw up the terminal in many cases, so I wouldn’t say this is fixed yet. Steps for Python 3 in a small 80 × 25 terminal on Linux:

* import _pyio; help(_pyio)
* Hit Ctrl-C

Steps for Python 2:

* import _pyio; help(_pyio)
* Hit Ctrl-C
* Hit Space ten times to scroll down. Alternatively, hit Ctrl-C a second time.

I am posting a quick patch which I think should fix this in Python 3 by deferring the traceback until after the child has finished. Another method is using the signal module like <https://github.com/vadmium/pacman-tools/blob/9ffdd88/roopwn#L976>, but that’s probably too platform-specific for the pydoc module.
msg239537 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-30 00:15
Here is a version that keeps things clean by not diplaying the traceback.  The ctl-c does have an effect, but not a visible one unless one pays careful attention :)
msg239541 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-03-30 00:54
I think your patch should be fine for all practical cases I can think of.
msg239612 - (view) Author: Roundup Robot (python-dev) Date: 2015-03-30 14:17
New changeset 7a5f30babc72 by R David Murray in branch '3.4':
#23792: also catch interrupt around pipe.write.
https://hg.python.org/cpython/rev/7a5f30babc72

New changeset 536c4f4acae1 by R David Murray in branch 'default':
Merge: #23792: also catch interrupt around pipe.write.
https://hg.python.org/cpython/rev/536c4f4acae1
msg239614 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-30 14:45
Yeah, someone could theoretically manage to hit ctl-c between the time the process is started and the call to pipe.write, or between it and the call to wait, but I don't think those very-low-probability events are worth worrying about.
msg246845 - (view) Author: (swanson) Date: 2015-07-17 07:38
Changing the title in case anyone else is looking for this bug.

This is not raw mode.  It's just that echo is turned off.

It is sufficient to type (invisibly, of course):
stty echo
to resume normal use of the terminal.
msg246853 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-07-17 14:03
Well, not exactly.  While the title was inaccurate, the real problem was the management of the subprocess, not what mode the terminal was in.
History
Date User Action Args
2015-07-17 14:03:39r.david.murraysetmessages: + msg246853
2015-07-17 07:38:40swansonsetnosy: + swanson

messages: + msg246845
title: help crash leaves terminal in raw mode -> help crash leaves terminal in echo off mode
2015-03-30 14:45:41r.david.murraysetmessages: + msg239614
2015-03-30 14:17:56python-devsetmessages: + msg239612
2015-03-30 00:54:42martin.pantersetmessages: + msg239541
2015-03-30 00:15:59r.david.murraysetfiles: + catch_additional_interrupt.patch

messages: + msg239537
2015-03-29 23:47:50martin.pantersetfiles: + interrupt.patch

messages: + msg239535
2015-03-29 19:21:10r.david.murraysetstatus: open -> closed
resolution: fixed
messages: + msg239512

stage: commit review -> resolved
2015-03-29 19:20:15python-devsetnosy: + python-dev
messages: + msg239511
2015-03-28 16:59:52r.david.murraysetmessages: + msg239460
2015-03-28 00:44:33martin.pantersetnosy: + martin.panter
messages: + msg239446
2015-03-27 19:35:14r.david.murraysetstage: patch review -> commit review
2015-03-27 19:35:03r.david.murraysetfiles: + keyboardinterrupt_in_pydoc_pager.patch

messages: + msg239431
2015-03-27 19:19:55r.david.murraysetmessages: + msg239429
2015-03-27 19:11:23ezio.melottisetmessages: + msg239428
stage: patch review
2015-03-27 19:08:52r.david.murraysetfiles: + keyboardinterrupt_in_pydoc_pager.patch
keywords: + patch
messages: + msg239427
2015-03-27 18:25:04r.david.murraysetmessages: + msg239426
2015-03-27 17:50:51ezio.melottisetversions: + Python 3.5
nosy: + ezio.melotti

messages: + msg239423

type: crash -> behavior
2015-03-27 17:50:14berker.peksagsetnosy: + berker.peksag
messages: + msg239422
2015-03-27 17:37:17r.david.murraysetnosy: + r.david.murray
messages: + msg239420
2015-03-27 17:09:23RusiModycreate