zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: SIGPIPE (Re: ZSH history not saved anymore)
Date: Sun, 28 Sep 2014 13:16:27 -0700	[thread overview]
Message-ID: <140928131627.ZM4749@torch.brasslantern.com> (raw)
In-Reply-To: <20140928191850.61c28815@pws-pc.ntlworld.com>

On Sep 28,  7:18pm, Peter Stephenson wrote:
}
} So in the first case I presume we're exiting (silently) on SIGPIPE.  That
} should be just a question of checking if SIGPIPE is trapped and if it isn't
} setting the handler to the default in entersubsh().  There's some partial
} prior art for this.

It gets a little stranger - this is again before the patch:

torch% TRAPPIPE() { : }                                              
torch% (sleep 5; echo hello; print -u2 $sysparams[pid] continued after PIPE) |
(exit)
TRAPPIPE: write error: broken pipe
echo: write error: broken pipe
zsh: write error: broken pipe
3579 continued after PIPE


Why did TRAPPIPE() receive a SIGPIPE?  And then:

torch% TRAPPIPE() { print -u2 $sysparams[pid] }
torch% (sleep 5; echo hello; print -u2 $sysparams[pid] continued after PIPE) |
(exit)
3659
TRAPPIPE: write error: broken pipe
3659
echo: write error: broken pipe
zsh: write error: broken pipe
3659 continued after PIPE


Note all calls to TRAPPIPE were in the subshell, and that it was called
more than once.

I think the following patch now covers keeping all this weird behavior
the same, while still zexit()'ng if SHTTY is lost.  There may remain
cases where a top-level non-interactive shell now calls _exit(SIGPIPE)
where it did not before, but I'm not sure how to test for those.  Just
doing 'kill -PIPE' of 'zsh -fc "sleep 10"' exits 141 both before and
after the patch below.  TRAPEXIT() has never been called on SIGPIPE.

I'm not entirely happy about examining forklevel in the very last hunk,
but it's the only value passed out of entersubsh() that seems to make
sense for this.  That hunk is restoring zsh's handler when a user-defined
trap is removed; without it, defining and then removing TRAPPIPE would
instead restore the OS default SIGPIPE handling.

I'd be grateful if somebody else could invent a regression test for this,
perhaps in Test/C03traps.ztst ?

diff --git a/Src/exec.c b/Src/exec.c
index fb2739a..fbd3095 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -1005,6 +1005,8 @@ entersubsh(int flags)
 	signal_default(SIGTERM);
 	if (!(sigtrapped[SIGINT] & ZSIG_IGNORED))
 	    signal_default(SIGINT);
+	if (!(sigtrapped[SIGPIPE]))
+	    signal_default(SIGPIPE);
     }
     if (!(sigtrapped[SIGQUIT] & ZSIG_IGNORED))
 	signal_default(SIGQUIT);
diff --git a/Src/init.c b/Src/init.c
index 40f46a8..6d005dc 100644
--- a/Src/init.c
+++ b/Src/init.c
@@ -1134,6 +1134,7 @@ init_signals(void)
     winch_block();	/* See utils.c:preprompt() */
 #endif
     if (interact) {
+	install_handler(SIGPIPE);
 	install_handler(SIGALRM);
 	signal_ignore(SIGTERM);
     }
diff --git a/Src/signals.c b/Src/signals.c
index cb2b581..84a2609 100644
--- a/Src/signals.c
+++ b/Src/signals.c
@@ -594,6 +594,17 @@ zhandler(int sig)
 	wait_for_processes();
         break;
  
+    case SIGPIPE:
+	if (!handletrap(SIGPIPE)) {
+	    if (!interact)
+		_exit(SIGPIPE);
+	    else if (!isatty(SHTTY)) {
+		stopmsg = 1;
+		zexit(SIGPIPE, 1);
+	    }
+	}
+	break;
+
     case SIGHUP:
         if (!handletrap(SIGHUP)) {
             stopmsg = 1;
@@ -897,6 +908,8 @@ removetrap(int sig)
 	noholdintr();
     } else if (sig == SIGHUP)
         install_handler(sig);
+    else if (sig == SIGPIPE && interact && !forklevel)
+        install_handler(sig);
     else if (sig && sig <= SIGCOUNT &&
 #ifdef SIGWINCH
              sig != SIGWINCH &&


  reply	other threads:[~2014-09-28 20:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87mw9qdp7s.fsf@thinkpad-t440p.tsdh.org>
     [not found] ` <20140924200710.2f764272@pws-pc.ntlworld.com>
     [not found]   ` <8738bg2n1v.fsf@thinkpad-t440p.tsdh.org>
     [not found]     ` <140926000448.ZM30835@torch.brasslantern.com>
     [not found]       ` <878ul6lrw9.fsf@thinkpad-t440p.tsdh.org>
     [not found]         ` <CABx2=D9xdeJ0qDNayUG0astemFEtK13SLpA3j8UQT5EqHW_PmA@mail.gmail.com>
     [not found]           ` <87y4t66td0.fsf@thinkpad-t440p.tsdh.org>
     [not found]             ` <CABx2=D-chwqBDZLTk8OqeUDqxvnYUQFFKWbiw7h3ZgUGtSb_CQ@mail.gmail.com>
     [not found]               ` <871tqxqyil.fsf@thinkpad-t440p.tsdh.org>
2014-09-27 17:53                 ` Bart Schaefer
2014-09-27 20:40                   ` Peter Stephenson
2014-09-27 23:55                     ` Bart Schaefer
2014-09-28 18:04                       ` Bart Schaefer
2014-09-28 18:18                         ` Peter Stephenson
2014-09-28 20:16                           ` Bart Schaefer [this message]
2014-09-29  8:45                             ` Peter Stephenson
2014-09-29 15:29                               ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=140928131627.ZM4749@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).