[issue1700304] pydoc.help samples sys.stdout and sys.stdin at import time
François Granade added the comment: issue8198 is related. Re. 1700304, it's easy to work around by writing from pydoc import help import sys help.output = sys.stdout help.input = sys.stdin -- nosy: +farialima ___ Python tracker <http://bugs.python.org/issue1700304> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8198] Importing pydoc and overwriting sys.stdout, causes one char to be sent to the console when calling help()
New submission from François Granade : When the "pydoc" module is imported, and the sys.stdout is overwriten, a end-of-line is sent to the console (on sdtout) when the help() function is sent. to reproduce (this is on Python 2.5 but the same happens on Pythjon 3.1): bash-3.2$ python2.5 -c "import pydoc; import sys; from StringIO import StringIO; sys.stdout = StringIO(); help(sys)" bash-3.2$ (note the one empty line) whereas: bash-3.2$ python2.5 -c "import sys; from StringIO import StringIO; sys.stdout = StringIO(); help(sys)" bash-3.2$ (no empty line) The funny thing is that the difference only occurs if sys.stdout is redirected; if it is not, importing pydoc doesn't change anything to the output: bash-3.2$ python2.5 -c "import pydoc; import sys; help(sys)" | wc 2561298 10690 bash-3.2$ python2.5 -c "import sys; help(sys)" | wc 2561298 10690 bash-3.2$ Note that this is related to 1700304, but is actually *one specific case* since *only one character* is not redirected - I would expect them all or none -- components: Library (Lib) messages: 101479 nosy: farialima severity: normal status: open title: Importing pydoc and overwriting sys.stdout, causes one char to be sent to the console when calling help() versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.org/issue8198> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5898] Hang in Popen.wait() when another process has been created
François Granade added the comment: Note that I use this wait(), otherwise, on CygWin, proc1 does not properly dies, and leaves opened (undeletable - that's windows !) files around -- ___ Python tracker <http://bugs.python.org/issue5898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5898] Hang in Popen.wait() when another process has been created
New submission from François Granade :
If I remove the "proc2.stdin.close()" in the script below, the
"proc1.wait()" will hang. Tested on MacOS, Linux, CygWin on 2.5.2 and
2.6. Is it a bug ?
from subprocess import Popen, PIPE
proc1 = Popen('cat -', shell=True, stdin=PIPE, stdout=PIPE)
proc2 = Popen('cat -', shell=True, stdin=PIPE, stdout=PIPE)
# Removing this line make the proc1.wait() hang
proc2.stdin.close()
proc1.stdin.close()
proc1.wait()
--
components: Library (Lib)
messages: 86901
nosy: farialima
severity: normal
status: open
title: Hang in Popen.wait() when another process has been created
type: behavior
versions: Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue5898>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3002] shutil.copyfile blocks indefinitely on named pipes
François Granade added the comment: Note that the 'cp' user command in Linux blocks also. Although this is *very* painful, you could argue that since the OS commands do the same thing, it shouldn't be fixed. -- nosy: +farialima ___ Python tracker <http://bugs.python.org/issue3002> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
