From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3) with ESMTP id NAA06481 for ; Sun, 28 Apr 1996 13:46:10 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id XAA25148; Sat, 27 Apr 1996 23:17:33 -0400 (EDT) Resent-Date: Sat, 27 Apr 1996 23:17:33 -0400 (EDT) From: Zoltan Hidvegi Message-Id: <199604280317.FAA06136@hzoli.ppp.cs.elte.hu> Subject: Re: echo $(wc <(wc /vmunix) <(wc /vmunix)) To: aheading@jpmorgan.com (Anthony Heading) Date: Sun, 28 Apr 1996 05:17:12 +0200 (MET DST) Cc: zsh-workers@math.gatech.edu In-Reply-To: <199604251810.TAA00347@gmp-etpres1.uk.jpmorgan.com> from Anthony Heading at "Apr 25, 96 07:10:47 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: application/pgp; format=text; x-action=sign Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TbFUA.0.p86.CDkWn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/964 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu -----BEGIN PGP SIGNED MESSAGE----- > The command in the subject line: `echo $(wc <(wc /vmunix) <(wc /vmunix))' locks up > zsh (at least my version 2.6-beta13-hzoli13 on SunOS 4.1.3) when ^C is hit immediately > after hitting return. I'm afraid I've no idea why, but it's obviously a bit tedious. > Maybe I'll use =(...) instead - that seems to work ok. That's not a zsh bug. Bash has the same problem. When you use <(...) zsh creates a named pipe and forks a process to write it. But if ^C is hit in an unfortunate moment, it may happen that the pipe is already opened for writing but the parent process was interrupted before it opend the pipe for reading. The open(pnam, O_WRONLY) call blocks until someone reads from the pipe. Zsh forks for the $(...) substitution and disables the MONITOR option. Then it forks again for <(...) but this time MONITOR is already unset, and the <(...) is an asynchronous command, so it ignores SIGINT and SIGQUIT as described in the manual. But this still does not explain why zsh freezes. The original shell does not ignore SIGINT. Its child is already terminated but remains zombie until the grandchild (which is waiting in open) exits. So I do not completely understand what's that. It may even be a kernel bug. But I think there is no harm in calling entersubshell (which disables SIGINT) only after the open. The patch below fixes this in the baseline release. It is already fixed in beta15-hzoli14. Bye, Zoltan *** exec.c.orig Sun Apr 28 03:40:58 1996 --- exec.c Sun Apr 28 03:40:27 1996 *************** *** 2037,2049 **** popheap(); return pnam; } - entersubsh(Z_ASYNC, 1, 0); closem(); fd = open(pnam, O_WRONLY); if (fd == -1) { zerr("can't open %s: %e", pnam, errno); _exit(1); } redup(fd, 1); fd = open("/dev/null", O_RDONLY); redup(fd, 0); --- 2037,2049 ---- popheap(); return pnam; } closem(); fd = open(pnam, O_WRONLY); if (fd == -1) { zerr("can't open %s: %e", pnam, errno); _exit(1); } + entersubsh(Z_ASYNC, 1, 0); redup(fd, 1); fd = open("/dev/null", O_RDONLY); redup(fd, 0); *************** *** 2089,2097 **** popheap(); return pnam; } - entersubsh(Z_ASYNC, 1, 0); closem(); fd = open(pnam, O_RDONLY); redup(fd, 0); execlist(list, 0, 1); _exit(lastval); --- 2089,2097 ---- popheap(); return pnam; } closem(); fd = open(pnam, O_RDONLY); + entersubsh(Z_ASYNC, 1, 0); redup(fd, 0); execlist(list, 0, 1); _exit(lastval); -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMYLjMwupSCiLN749AQGKaAQAmNwHELJWoJatn5c/NGMxRO80zmEiUaQe 6nS0tfsGYdHVRPHPLIbCwFLPpFl0XdG8bsdRuMX/6lrcSVGrkhtld2/7V4X34T89 BjbxTNmtZrnihcbFddkFsfFJIeOO0gfEYzErTHtn4X6rdcHbRFMrdZkcRMqOu92a lHQU0zFnrqg= =Y+Df -----END PGP SIGNATURE-----