On Mon, Apr 8, 2024 at 11:07 AM Chet Ramey <chet.ra...@case.edu> wrote: > > Bash doesn't close the file descriptor in $fd. Since it's used with `exec', > it's under the user's control. > > The script here explicitly opens and closes the file descriptor, so it > can read until read returns failure. It doesn't really matter when the > process exits or whether the shell closes its ends of the pipe -- the > script has made a copy that it can use for its own purposes.
> (And you need to use exec to close it when you're done.) Caught that shortly after sending the email. Yeah, I know. > You can do the same thing with a coproc. The question is whether or > not scripts should have to. If there's a way to exec fds to read from and write to the same background process without first using the coproc keyword or using FIFOs I'm all ears. To me, coproc fills that gap. I'd be fine with having to close the coproc fds in subshells myself. Heck, you still have to use exec to close at least the writing coproc fd in the parent process to get the coproc to exit, regardless. The fact that the current implementation allows the coproc fds to get into process substitutions is a little weird to me. A process substitution, in combination with exec, is kind of the one other way to communicate with background processes through fds without using FIFOs. I still have to close the coproc fds there myself, right now. Consider the following situation: I've got different kinds of background processes going on, and I've got fds exec'd from process substitutions, fds from coprocs, and fds exec'd from other things, and I need to keep them all out of the various background processes. Now I need different arrays of fds, so I can close all the fds that get into a background process forked with & without trying to close the coproc fds there; while still being able to close all the fds, including the coproc fds, in process substitutions. I'm curious what the reasoning was there.
