Nick Coghlan added the comment:
It seems this can be triggered easily with echo, since that appears to reliably
close stdin on startup (Discovered via
http://stackoverflow.com/questions/16314321).
Compare (using a recent trunk build, although I see the same behaviour with the
system 3.3 installation):
$ ../py3k/python -c 'print("Hello world!")' | echo
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w'
encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe
$ ../py3k/python -c 'print("Hello world!")' | xargs echo
Hello world!
$ ../py3k/python -c 'print("Hello world!")' | cat
Hello world!
Given that flush/close related exceptions are automatically ignored in
destructors, something else must be going on here.
It turns out that the *explicit* flush calls during interpreter finalization
use PyErr_WriteUnraisable on failure to flush stdout instead of silently
ignoring the exceptions
(http://hg.python.org/cpython/file/ed011b0d7daf/Python/pythonrun.c#l457).
This is reasonable, since a broken pipeline *is* an error that the user may
need to do something about (e.g. as with echo, they next pipeline stage may not
being invoked correctly, thus breaking the pipe)
However, in the specific case of a broken pipe, I believe it is desirable for
us to write out a cleaner message than the generic PyErr_WriteUnraisable output.
----------
nosy: +ncoghlan, pitrou
title: "close failed in file object destructor" when "Broken pipe" happens on
stdout -> Improve reporting of broken stdout pipe during interpreter shutdown
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue11380>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
