From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10015 invoked from network); 10 Oct 1999 21:12:06 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Oct 1999 21:12:06 -0000 Received: (qmail 2182 invoked by alias); 10 Oct 1999 21:11:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8192 Received: (qmail 2175 invoked from network); 10 Oct 1999 21:11:52 -0000 From: "Bart Schaefer" Message-Id: <991010211147.ZM2563@candle.brasslantern.com> Date: Sun, 10 Oct 1999 21:11:47 +0000 In-Reply-To: Comments: In reply to Zefram "Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness" (Oct 10, 6:41pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 10, 6:53pm, Zefram wrote: } Subject: Re: PATCH: Re: PATCH: no more fd mixups } } Bart Schaefer wrote: } >Here's a tweak to Zefram's patch to [...] test } >that the descriptor is in the fdtable[] array, } } At the moment, coprocess fds do not get passed on to children, but they } are explicitly marked as public in fdtable[], and hence after your patch } they are dupable by number. Yes, that's true. While we're on the topic: zagzig[21] coproc tr a-z A-Z [1] 2510 zagzig[22] exec 5<&p zagzig[23] ls -l /proc/self/fd total 0 lrwx------ 1 schaefer schaefer 64 Oct 10 13:48 0 -> [0301]:11232 lrwx------ 1 schaefer schaefer 64 Oct 10 13:48 1 -> [0301]:11232 lrwx------ 1 schaefer schaefer 64 Oct 10 13:48 2 -> [0301]:11232 lr-x------ 1 schaefer schaefer 64 Oct 10 13:48 3 -> [0001]:164691976 lr-x------ 1 schaefer schaefer 64 Oct 10 13:48 5 -> [0000]:12364629 Should descriptor 5 have been passed on to "ls" in this manner? (Note that /proc/self/fd are the fds of "ls" at that point, not of the shell.) } I *think* all that needs to change is to remove the line } } fdtable[coprocin] = fdtable[coprocout] = 0; I'm concerned about that because there are other places where the fds with nonzero entries in fdtable[] are either closed, or deliberately kept open, in circumstances that may not apply to the coproc. In particular, I think it would break this: coproc foo bar <(baz <&p) Probably it's better to just extend the test we've already tweaked twice now, so that it explicitly tests the coproc fds as well. Index: exec.c =================================================================== @@ -1671,7 +1671,10 @@ case MERGEOUT: if (fn->fd2 < 10) closemn(mfds, fn->fd2); - if (fn->fd2 > 9 && fdtable[fn->fd2]) { + if (fn->fd2 > 9 && + (fdtable[fn->fd2] || + fn->fd2 == coprocin || + fn->fd2 == coprocout)) { fil = -1; errno = EBADF; } else { -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com