Colin Watson reports that gnome-session has been known to leave

SIGPIPE ignored in its child processes, leading to unexpected
behaviour inside pterms. (The gnome-session I'm sitting in front of
doesn't seem to do this as far as I can tell, but I don't doubt there
are some that do.) Add SIGPIPE to the list of signals we reset to
default behaviour before launching pterm's child process.

git-svn-id: svn://svn.tartarus.org/sgt/putty@9117 cda61777-01e9-0310-a592-d414129be87e

diff --git a/unix/uxpty.c b/unix/uxpty.c
index 16ad6e2..bdfa5ab 100644 (file)
--- a/unix/uxpty.c
+++ b/unix/uxpty.c
@@ -826,14 +826,15 @@ static const char *pty_init(void *frontend, void **backend_handle, Config *cfg,
        }
 
        /*
-        * SIGINT and SIGQUIT may have been set to ignored by our
-        * parent, particularly by things like sh -c 'pterm &' and
-        * some window managers. SIGCHLD, meanwhile, was blocked
-        * during pt_main() startup. Reverse all this for our child
-        * process.
+        * SIGINT, SIGQUIT and SIGPIPE may have been set to ignored by
+        * our parent, particularly by things like sh -c 'pterm &' and
+        * some window or session managers. SIGCHLD, meanwhile, was
+        * blocked during pt_main() startup. Reverse all this for our
+        * child process.
         */
        putty_signal(SIGINT, SIG_DFL);
        putty_signal(SIGQUIT, SIG_DFL);
+       putty_signal(SIGPIPE, SIG_DFL);
        block_signal(SIGCHLD, 0);
        if (pty_argv)
            execvp(pty_argv[0], pty_argv);