I guess the question remains, why does a "here string" assigned to a named FD rely on the system to the the clean-up but when assigned to a regular, numbered FD, it does not?
The issue I see with relying on the bash EXIT to actually have the system do the cleanup is when you have a script that does things in a forever loop, you end up with FD exhaustion when using "named" FD and here strings. (kind of what my original script was showing) Say you have a "ulimit -f 1024, and you do more than 1024 iterations of the function, you clearly end up with a "Too many open files". Again, not the case if I do the same thing with a regular FD number.
Similar scenario if you replace the "here string" with the process substitution output...
The issue does not seams to be with the "here string" at all, but the use of the "named" FD.
Again, simple example of this idea, i.e. let's watch for a file and do something if found. Assuming a f ulimit of 1024, this will stop printing at about 1011 on my system
ittr=0
while :; do
while read -r -u $fh fname; do
if [[ $fname == file3 ]]; then
printf "$((ittr++)), "
# we could delete the file here and wait for the
# next time it appears, etc... Just an example.
fi
done {fh}< <(ls -1)
# we would normally wait some time here.
#sleep 1
[[ $? -ne 0 ]] && exit $?
done
But this will go on forever:
ittr=0
while :; do
while read -r -u 9 fname; do
if [[ $fname == file3 ]]; then
printf "$((ittr++)), "
# we could delete the file here and wait for the
# next time it appears, etc... Just an example.
fi
done 9< <(ls -1)
# we would normally wait some time here.
#sleep 1
[[ $? -ne 0 ]] && exit $?
done
Same thing with the "here" string, the following will print forever, but not if I replace the 9 with $fh...
ittr=0
while :; do
while read -r -u 9 fname; do
if [[ $fname == file3 ]]; then
printf "$((ittr++)), "
# we could delete the file here and wait for the
# next time it appears, etc... Just an example.
fi
done 9<<<"file3"
# we would normally wait some time here.
#sleep 1
[[ $? -ne 0 ]] && exit $?
done
Again, thanks for looking into this weirdness.