This prevents send(2) from terminating the whole process with SIGPIPE
if the socket has gone away. Since PuTTY manages multiple network
connections (due to port forwarding and X11 forwarding), and some of
the outlying tools like psusan can manage even more (multiple entire
sessions running at once), you never want the whole application to die
of SIGPIPE in this situation: you just want that one
connection (perhaps a forwarding) to be cleanly aborted, and a failure
indication sent back over another connection. Even if the main
connection really does get EPIPE, you'd still prefer a sensible error
message.
I tried using psusan this week to forward X11 into a Podman container,
by means of sharing a host directory into the container, making psusan
bind to a Unix socket in that directory, and telling host PuTTY to
connect to that Unix socket and speak bare ssh-connection. The X
application locked up mysteriously, and when I tried to ^C it from the
main host PuTTY window, psusan in the container died of SIGPIPE at
this call site.
(The locked-up X app was pterm, which would also be worrying if it
weren't for the fact that I can't reproduce it on current main, only
on 0.83. I suspect Ben's many recent GTK improvements have fixed
something in this area in passing.)
91ad3af01c