[Python-Dev] Help preventing SIGPIPE/SIG_DFL anti-pattern.

[Guido van Rossum]

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, SIG_DFL)" 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>