There will be a shell option to force the auto-close behavior in the next version. The option name is still up for grabs; it's currently `varredir_close'.

When using redirection with {varname}<>filename syntax, bash does not close an opened file automatically (unlike ksh93, for example). This behavior looks strange to me.

If I wanted to keep the file open until I close it explicitly, I would use exec:

    exec {fd}<>file

But sometimes I want bash to take care about closing the FD, like ksh does, and I don't want to hardcode FD numbers to avoid accidental collisions. E.g. if I lock a file:

    {
        flock $fd
        # do something useful with file
    } {fd}<>file

Of course, I could close the FD in the end of the block or immediately after it:

    {
        flock $fd
        # do something useful with file
    } {fd}<>file; exec {fd}>&-

But there is a problem that if execution interrupts inside the block, the file remains locked. And if after interruption some cleanup routine is executed that also tries to acquire lock on this file, the whole process will be deadlocked. So this solution is unacceptable.

Another possible workaround is to use a subshell:

    (
        flock $fd
        # do something useful with file
    ) {fd}<>file

But I would prefer to execute the whole script in a single process when possible.

That's why I think that current behavior of bash is a result of bad design. Of course, it is impossible to change it by default because this would break backwards compatibility. But it would be nice to add an option that will enable ksh-like behavior.