|
From: | Chet Ramey |
Subject: | Re: Examples of concurrent coproc usage? |
Date: | Mon, 8 Apr 2024 11:07:48 -0400 |
User-agent: | Mozilla Thunderbird |
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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |