[Python-Dev] Help preventing SIGPIPE/SIG_DFL anti-pattern. (original) (raw)

Guido van Rossum guido at python.org
Sun Jul 1 01:50:48 EDT 2018

On Sat, Jun 30, 2018 at 9:02 PM Alfred Perlstein <alfred at freebsd.org> wrote:

On 6/30/18 4:20 PM, Greg Ewing wrote: > Alfred Perlstein wrote: >> I am asking if there's a way we can discourage the use of >> "signal(SIGPIPE, SIGDFL)" unless the user really understands what >> they are doing. > > Maybe there's some way that SIGPIPEs on stdout could be handled > differently by default, so that they exit silently instead of > producing an ugly message. That would remove the source of pain > that's leading people to do this. > Thank you Greg, I can poke around into this, it would be a bit of a challenge as the descriptor which causes BrokenPipeError does not appear to be stored within the exception so differentiating it from other exceptions might be a bit tricky. I will look into this in the coming weeks. Any tips on accomplishing this? I was thinking of encoding the fd responsible for causing the error into the exception somehow and then checking to see if it was stdout, then not reporting on it.

There's PyErr_SetFromErrnoWithFilenameObject(), which generates an OSError with a filename. We could have a similar call PyErr_SetFromErrnoWithFileDescriptor(), which generates an OSError (or a subclass like BrokenPipeError) with a file descriptor. Just pick a new attribute name to store the fd on, e.g. file_descriptor (I guess it would default to None). Then of course you will have to write the code that calls this instead of plain PyErr_SetFromErrno() for those syscalls where a file descriptor is present.

And when Python exits with a BrokenPipeError it could suppress printing the stack trace when the file_descriptor field equals 1.

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180630/88c09205/attachment.html>

More information about the Python-Dev mailing list