On Sat, Jun 30, 2018 at 9:02 PM Alfred Perlstein 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
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,
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
pro
Hello,
I'm looking for someone in the python community to help with a problem
of anti-patterns showing up dealing with SIGPIPE.
Specifically I've noticed an anti-pattern developing where folks will
try to suppress broken pipe errors written to stdout by setting
SIGPIPE's disposition to SIG_D
(sorry for the double post, looks like maybe attachments are dropped,
inlined the attachment this time.)
Hello,
I'm looking for someone in the python community to help with a problem
of anti-patterns showing up dealing with SIGPIPE.
Specifically I've noticed an anti-pattern developing where
