On 4/3/24 1:19 PM, Zachary Santer wrote:
> On Wed, Apr 3, 2024 at 10:32 AM Chet Ramey <chet.ramey@case.edu> wrote:
>>
>> How long should the shell defer deallocating the coproc after the process
>> terminates? What should it do to make sure that the variables don't hang
>> around with invalid file descriptors? Or should the user be responsible for
>> unsetting the array variable too? (That's never been a requirement,
>> obviously.)
> 
> For sake of comparison, and because I don't know the answer, what does
> bash do behind the scenes in this situation?
> 
> exec {fd}< <( some command )
> while IFS='' read -r line <&"${fd}"; do
>    # do stuff
> done
> {fd}<&-
> 
> Because the command in the process substitution isn't waiting for
> input, (I think) it could've exited at any point before all of its
> output has been consumed. Even so, bash appears to handle this
> seamlessly.

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.)

You can do the same thing with a coproc. The question is whether or
not scripts should have to.

-- 
``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/