Martin Panter added the comment:
Issue 33550 was opened about Mike’s case of ignoring broken pipe conditions.
BTW a side effect of closing sys.stderr is that error messages reported by
interpreter shutdown will be missing (even if there was no broken pipe). For
example, exception messages
Robert Collins added the comment:
Oh, just saw your comment Martin; yes, this does look like a dupe.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11380
___
Robert Collins added the comment:
Bah, wrong issue. Sorry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11380
___
___
Python-bugs-list mailing
Robert Collins added the comment:
@zzeeek
For Python 3 pipeline tools you need something like this:
try:
all your stuff
finally:
try:
sys.stdout.flush()
finally:
try:
sys.stdout.close()
finally:
try:
sys.stderr.flush()
Robert Collins added the comment:
See also issue24864 which is not *quite* a dupe, I also found that it exits 0,
unreasonably so.
The reporting thing is interesting, but the main thing I care about is that we
can catch it and do something reasonable with it... and that if not caught it
Changes by Christopher Heiny christopherhe...@gmail.com:
--
nosy: +Christopher.Heiny
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11380
___
___
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +flox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11380
___
___
Python-bugs-list
Changes by Dillon Aumiller dillonaumil...@gmail.com:
--
nosy: +daumiller
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11380
___
___
mike bayer added the comment:
my users are reporting one of these issues, and while I can easily catch
IOError on Python 2, I can't catch anything on Python 3, and pointing SIGPIPE
to SIG_DFL isn't an option because this is for Alembic migrations and the
command needs to complete its work.
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
Antoine Pitrou added the comment:
I'm not sure I understand Nick's suggestion. As far as I can tell, the issue is
to detect that write() (really fwrite() in 2.x) failed and output the error.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Ah, actually, the real issue is that sys.stderr is gone by the time we try to
print the exception (which explains the lost sys.stderr message).
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Here is a patch, lacking tests.
How important it is to fix this in 2.7 I'm not sure. People are certainly used
to the quirk now, and it's generally harmless.
--
keywords: +patch
Added file:
Nick Coghlan added the comment:
My specific suggestion was aimed at 3.4 - I think reporting the failure to
flush stdout on stderr is the right thing to do (since data may have been
lost and people can suppress it by closing stdout early, including in an
atexit handler), but I also think it's
Antoine Pitrou added the comment:
My specific suggestion was aimed at 3.4 - I think reporting the failure to
flush stdout on stderr is the right thing to do (since data may have been
lost and people can suppress it by closing stdout early, including in an
atexit handler), but I also think
Nick Coghlan added the comment:
Suppress the traceback, avoid printing the exception repr and instead
display something more like Broken pipe: receiving end of stdout closed
prior to interpreter shutdown
--
___
Python tracker rep...@bugs.python.org
16 matches
Mail list logo
