SIGPIPE handling

SIGPIPE handling

[Zoltan Hidvegi]

Since it seems that noone know why SIGPIPE is trapped for shells under job
control, let's try to remove this.  This change only affects interactive
shells since when MONITOR is not set SIGPIPE is not handled specially.  And
since SIGPIPE is not related to process groups and not used for job
control, it should not be a special case.  Probably it was just an
oversight when some developer thought that SIGPIPE is in the same category
as SIGT{OU,IN,STP} signals.  SIGPIPE is still not reported after this
patch.  In bash, cat builtin.c | : reports `Broken pipe' while zsh and ksh
and pdksh remains silent, which is better I think.

This patch should be applied to zsh-3.0 as well.  The jobs.c hunk will be
rejected.  Just apply this rejected patch to builtin.c using

patch builtin.c jobs.c.rej

Alternatively you can edit the patch and replace jobs.c with builtin.c.

Zoltan


*** Src/signals.c	1997/05/18 09:04:56	3.1.2.5
--- Src/signals.c	1997/05/18 18:38:40
***************
*** 590,597 ****
  {
      if (sig == -1)
          return 1;
!     if (jobbing && (sig == SIGTTOU || sig == SIGTSTP ||
! 		    sig == SIGTTIN || sig == SIGPIPE)) {
          zerr("can't trap SIG%s in interactive shells", sigs[sig], 0);
          return 1;
      }
--- 590,596 ----
  {
      if (sig == -1)
          return 1;
!     if (jobbing && (sig == SIGTTOU || sig == SIGTSTP || sig == SIGTTIN)) {
          zerr("can't trap SIG%s in interactive shells", sigs[sig], 0);
          return 1;
      }
***************
*** 625,632 ****
      int trapped;
  
      if (sig == -1 || !(trapped = sigtrapped[sig]) ||
! 	(jobbing && (sig == SIGTTOU || sig == SIGTSTP ||
! 		     sig == SIGTTIN || sig == SIGPIPE))) {
          return;
      }
      sigtrapped[sig] = 0;
--- 624,630 ----
      int trapped;
  
      if (sig == -1 || !(trapped = sigtrapped[sig]) ||
! 	(jobbing && (sig == SIGTTOU || sig == SIGTSTP || sig == SIGTTIN))) {
          return;
      }
      sigtrapped[sig] = 0;
*** Src/jobs.c	1997/05/18 09:09:03	3.1.2.4
--- Src/jobs.c	1997/05/18 18:36:33
***************
*** 1270,1276 ****
      }
      if (jobbing) {
  	/* stop ignoring signals */
- 	signal_default(SIGPIPE);
  	signal_default(SIGTTIN);
  	signal_default(SIGTSTP);
  	signal_default(SIGTTOU);
--- 1270,1275 ----
***************
*** 1288,1294 ****
  	signal_ignore(SIGTTOU);
  	signal_ignore(SIGTSTP);
  	signal_ignore(SIGTTIN);
- 	signal_ignore(SIGPIPE);
      }
      return 0;
  }
--- 1287,1292 ----
*** Src/init.c	1997/05/18 09:09:03	3.1.2.11
--- Src/init.c	1997/05/18 18:38:57
***************
*** 588,594 ****
  	    signal_ignore(SIGTTOU);
  	    signal_ignore(SIGTSTP);
  	    signal_ignore(SIGTTIN);
- 	    signal_ignore(SIGPIPE);
  	    attachtty(mypgrp);
  	}
      }
--- 588,593 ----
*** Src/exec.c	1997/05/18 09:04:56	3.1.2.9
--- Src/exec.c	1997/05/18 18:39:06
***************
*** 1936,1942 ****
  	signal_default(SIGTTOU);
  	signal_default(SIGTTIN);
  	signal_default(SIGTSTP);
- 	signal_default(SIGPIPE);
      }
      if (interact) {
  	signal_default(SIGTERM);
--- 1936,1941 ----

SIGPIPE handling

[Zoltan Hidvegi]

Zsh and ksh simply dies when they receive an untrapped SIGPIPE signal,
while bash and pdksh catch the signal, and exit with exit status 141.

If you call zsh or bash from a shell script, you'll not notice the
difference, since the shell reports exit status 141 for processes killed
by signal 13 = SIGPIPE, but the status returned by the wait() system call
is different, and for zsh and ksh, WIFSIGNALLED will be true, while for
bash and pdksh WIFEXITED will be true.  Reading the standard
(http://www.rdg.opengroup.org/unix/online.html) it seems to me that the
zsh and ksh behavior is the correct one, since that's the default signal
behavior, and the standard does not mentions that SIGPIPE should be
handled specially (Chet, if you are still reading this list, I'd like to
hear your opinion).

Unoftunately the install-info perl script in Debian relies on the bash
SIGPIPE behavior, hence fails when /bin/sh is zsh or ksh.  The patch
below for the Debian install-info program fixes the problem.  It still
allows the bash behavior.  Someone reported this problem long ago, but
at that time I did not use Debian, and I had no idea what can cause this.
Even now using Debian it took me a while to solve this puzzle.

Zoltan


--- /usr/sbin/install-info.ORIG	Sun Jan 26 01:15:02 1997
+++ /usr/sbin/install-info	Wed Sep  3 02:03:24 1997
@@ -345,7 +345,7 @@
 }
 
 sub checkpipe {
-    return if !$pipeit || !$? || $?==0x8D00;
+    return if !$pipeit || !$? || $?==0x8D00 || $?==0xD;
     die "$name: read $filename: $?\n";
 }