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]

I can't reproduce this. Maybe it is a debian bug?

This looks like a duplicate of bpo-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

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.

I do see the anomalous behavior inside python, but on my gentoo system when I exit python the terminal is fine.

The attached patch fixes the issue for me.

Patch WFM too.

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.

Updated patch.

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.

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.

New changeset 77c04e949b4b by R David Murray in branch '3.4':
bpo-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: bpo-23792: Ignore KeyboardInterrupt when the pydoc pager is active.
https://hg.python.org/cpython/rev/fe0c830b43bb

I've committed the fix. If someone wants to argue in favor of also handling SIGQUIT, they can open a new issue.

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.

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 :)

I think your patch should be fine for all practical cases I can think of.

New changeset 7a5f30babc72 by R David Murray in branch '3.4':
bpo-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: bpo-23792: also catch interrupt around pipe.write.
https://hg.python.org/cpython/rev/536c4f4acae1

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.

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.

Well, not exactly. While the title was inaccurate, the real problem was the management of the subprocess, not what mode the terminal was in.