From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness
Date: Sun, 10 Oct 1999 21:11:47 +0000 [thread overview]
Message-ID: <991010211147.ZM2563@candle.brasslantern.com> (raw)
In-Reply-To: <E11aMyg-0008VI-00@crucigera.fysh.org>
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
next prev parent reply other threads:[~1999-10-10 21:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-05 9:45 Bart Schaefer
1999-10-10 8:27 ` PATCH: 3.0.6/3.1.6: " Bart Schaefer
1999-10-10 13:35 ` Zefram
1999-10-10 15:54 ` Bart Schaefer
1999-10-10 16:39 ` PATCH: Re: PATCH: no more fd mixups Bart Schaefer
1999-10-10 17:53 ` Zefram
1999-10-10 21:11 ` Bart Schaefer [this message]
1999-10-11 8:12 ` PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness Zefram
1999-10-10 17:41 ` Zefram
1999-10-10 14:35 PATCH: no more fd mixups Zefram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=991010211147.ZM2563@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).