From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29699 invoked by alias); 19 Aug 2010 20:37:32 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 15301 Received: (qmail 13591 invoked from network); 19 Aug 2010 20:37:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at ntlworld.com designates 81.103.221.47 as permitted sender) Date: Thu, 19 Aug 2010 21:37:17 +0100 From: Peter Stephenson To: zsh-users@zsh.org Subject: Re: process substitution and Ctrl-C Message-ID: <20100819213717.5b5a7466@pws-pc> In-Reply-To: <100819083237.ZM26692@torch.brasslantern.com> References: <20100819124142.GQ16075@prunille.vinc17.org> <100819083237.ZM26692@torch.brasslantern.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=DhNl2YeytwJssBBGe49HJX82LNDFEEVkpVB34RXKaPo= c=1 sm=0 a=s8Rmg4McYNwA:10 a=DogomfpGjd0A:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=NLZqzBF-AAAA:8 a=RESZuSiyA2XkhT_BcH0A:9 a=HxS45wrhLtV32FSxTi4A:7 a=5_QZ8Zfl5HtxqNzKTp9BMsKfII4A:4 a=CjuIK1q_8ugA:10 a=I6wTmPyJxzYA:10 a=_dQi-Dcv4p4A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 On Thu, 19 Aug 2010 08:32:37 -0700 Bart Schaefer wrote: > If I try > > echo >>(cat; sleep 100) > > then the shell is effectively frozen until "sleep 100" finishes, because > "echo" is already gone and the process substitution is not interruptible, > so nothing is paying attention to ^C or ^Z etc. (This should have gone to zsh-workers ages ago but still hasn't.) This is a separate problem. It's not so much that the echo has gone as that there are no processes in the tty process group to get the signal, because the substitution is treated as asynchronous for the purposes of job handling. (In fact, I've decided I don't understand what "asynchronous" means in this case, either. We seem to have spent chunks of the last twenty years making process substitution less and less like an asynchronous process; first we started waiting for it to finish, now we're passing signals to it.) Any reactions to the following patch? This makes the substitution process always get the same signal as the rest of the command line. If that's an external process that would be interrupted, so you wouldn't see the freeze, but even there without the patch the "sleep" carries merrily on --- similar to Vincent's case. The alternative is to make it synchronous only if the current job is running within the shell. I no longer really have any idea what the intention is. I'm assuming the other use of >(...), when not part of a redirection, want identical treatment to whatever happens here. Index: Src/exec.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/exec.c,v retrieving revision 1.181 diff -p -u -r1.181 exec.c --- Src/exec.c 15 Jul 2010 18:44:13 -0000 1.181 +++ Src/exec.c 19 Aug 2010 20:26:24 -0000 @@ -3828,7 +3828,7 @@ getproc(char *cmd, char **eptr) zerr("can't open %s: %e", pnam, errno); _exit(1); } - entersubsh(ESUB_ASYNC|ESUB_PGRP); + entersubsh(ESUB_PGRP); redup(fd, out); #else /* PATH_DEV_FD */ int pipes[2]; @@ -3855,7 +3855,7 @@ getproc(char *cmd, char **eptr) } return pnam; } - entersubsh(ESUB_ASYNC|ESUB_PGRP); + entersubsh(ESUB_PGRP); redup(pipes[out], out); closem(FDT_UNUSED); /* this closes pipes[!out] as well */ #endif /* PATH_DEV_FD */ @@ -3905,7 +3905,7 @@ getpipe(char *cmd, int nullexec) addproc(pid, NULL, 1, &bgtime); return pipes[!out]; } - entersubsh(ESUB_ASYNC|ESUB_PGRP); + entersubsh(ESUB_PGRP); redup(pipes[out], out); closem(FDT_UNUSED); /* this closes pipes[!out] as well */ cmdpush(CS_CMDSUBST); -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/