On 4/9/24 10:46 AM, Zachary Santer wrote:

>> If you want two processes to communicate (really three), you might want
>> to build with the multiple coproc support and use the shell as the
>> arbiter.
> 
> If you've written a script for other people than just yourself,
> expecting all of them to build their own bash install with a
> non-default preprocessor directive is pretty unreasonable.

This all started because I wasn't comfortable with the amount of testing
the multiple coprocs code had undergone. If we can get more people to
test these features, there's a better chance of making it the default.

> The part that I've been missing this whole time is that using exec
> with the fds provided by the coproc keyword is actually a complete
> solution for my use case, if I'm willing to close all the resultant
> fds myself in background processes where I don't want them to go.
> Which I am.

Good deal.

> Whether the coproc fds should be automatically kept out of most kinds
> of subshells, like it is now; or out of more kinds than currently; is
> kind of beside the point to me now.

Sure, but it's the potential for deadlock that we're trying to reduce.

> But, having a builtin to ensure
> the same behavior is applied to any arbitrary fd might be useful to
> people, especially if those fds get removed from process substitutions
> as well.

What does this mean? What kind of builtin? And what `same behavior'?

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/