From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16382 invoked from network); 8 May 1999 17:01:09 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 May 1999 17:01:09 -0000 Received: (qmail 18532 invoked by alias); 8 May 1999 17:00:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6240 Received: (qmail 18524 invoked from network); 8 May 1999 17:00:46 -0000 Message-Id: <9905081636.AA46827@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: PATCH: 3.1.5-pws-17: read after pipeline bug Date: Sat, 08 May 1999 18:36:26 +0200 From: Peter Stephenson This looks like being an old bug, it's also in 3.0.5. zsh -f % echo foo | read foo; read foo % The (interactive) shell doesn't wait. It turns out the read gets an EIO --- repeatedly, so it's not a hang over from the previous read. I discovered read foo stat & STAT_CURSH)) { - lastval = val; - inforeground = 1; + if (job == thisjob) { + if (jn->stat & STAT_CURSH) + inforeground = 1; + else { + lastval = val; + inforeground = 2; + } } } @@ -223,7 +228,7 @@ * process group from the shell, so the shell will not receive * * terminal signals, therefore we we pretend that the shell got * * the signal too. */ - if (inforeground && isset(MONITOR) && WIFSIGNALED(status)) { + if (inforeground == 2 && isset(MONITOR) && WIFSIGNALED(status)) { int sig = WTERMSIG(status); if (sig == SIGINT || sig == SIGQUIT) { -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy