From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5141 invoked from network); 11 Jul 2000 17:19:50 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Jul 2000 17:19:50 -0000 Received: (qmail 26045 invoked by alias); 11 Jul 2000 17:19:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12223 Received: (qmail 26038 invoked from network); 11 Jul 2000 17:19:38 -0000 Date: Tue, 11 Jul 2000 18:18:57 +0100 From: Peter Stephenson Subject: Re: PATCH: Re: Multi-redirection bug In-reply-to: "Your message of Tue, 11 Jul 2000 17:59:21 BST." <0FXJ00MQFLUXDK@la-la.cambridgesiliconradio.com> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Message-id: <0FXJ00I0DMRLRK@la-la.cambridgesiliconradio.com> Content-transfer-encoding: 7BIT 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 Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070