PATCH: Re: Multi-redirection bug

PATCH: Re: Multi-redirection bug

[Peter Stephenson]

> Last year, I sent a mail to this mailing-list about a probable bug
> concerning zsh MULTIOS redirections. But there were no replies.
> Then, I thought it was solved... until now.
> 
> To be more clear, I take a simple (but useless) example. If I type
> the following command under zsh
> 
>     cat /dev/zero >/dev/null 2>|f1 2>|f2
> 
> I get two processes: "cat /dev/zero" and a child "zsh". But when
> I resize the terminal, the child dies (it becomes "<defunct>", as
> "cat /dev/zero" doesn't wait for it). And this prevents f1 or f2
> (or maybe both) from getting the data.

I find it hard to see anything with this variant, since stderr is empty
anyway.  But the basic problem seems to be real enough.  See if this fixes
it.  It fixes what I was seeing, but unfortunately that was rather worse:
the parent process got a SIGPIPE when the child exited, and that caused it
to crash.  The SIGPIPE is inevitable, but the shell usually doesn't exit on
it, so there may be something else wrong.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.11
diff -u -r1.11 exec.c
--- Src/exec.c	2000/07/11 16:43:26	1.11
+++ Src/exec.c	2000/07/11 16:56:25
@@ -1356,14 +1356,28 @@
 	closeallelse(mn);
 	if (mn->rflag) {
 	    /* tee process */
-	    while ((len = read(mn->pipe, buf, TCBUFSIZE)) > 0)
+	    while ((len = read(mn->pipe, buf, TCBUFSIZE)) != 0) {
+		if (len < 0) {
+		    if (errno == EINTR)
+			continue;
+		    else
+			break;
+		}
 		for (i = 0; i < mn->ct; i++)
 		    write(mn->fds[i], buf, len);
+	    }
 	} else {
 	    /* cat process */
 	    for (i = 0; i < mn->ct; i++)
-		while ((len = read(mn->fds[i], buf, TCBUFSIZE)) > 0)
+		while ((len = read(mn->fds[i], buf, TCBUFSIZE)) != 0) {
+		    if (len < 0) {
+			if (errno == EINTR)
+			    continue;
+			else
+			    break;
+		    }
 		    write(mn->pipe, buf, len);
+		}
 	}
 	_exit(0);
     }

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: PATCH: Re: Multi-redirection bug

[Peter Stephenson]

I wrote:
> The SIGPIPE is inevitable, but the shell usually doesn't exit on
> it, so there may be something else wrong.

This may be nonsense.

% (echo foo; sleep 1; echo bar >& 2) | (read >/dev/null)
bar
% (echo foo; sleep 1; echo foo2; echo bar >& 2) | (read >/dev/null)
% print $pipestatus                                                
141 0

The sleep is necessary so that the read process has really exited (`by a
sleep to say we end the heartache' etc.).  In that case the shell process
does get SIGPIPE (13 on Solaris + 128 for a signal) and exit.

Still, it worries me that it can be so drastically affected by the
behaviour of trivial subprocesses like the multios helpers.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070