helpThe GNU Bourne-Again SHell - Support: sr #110496, Option to automatically close...

 
 

sr #110496: Option to automatically close descriptors opened with {var}<>file

Submitted by:  None
Submitted on:  Fri 21 May 2021 07:35:32 PM UTC
Votes:  1  
 
Category:  None Priority:  5 - Normal
Severity:  1 - Wish Status:  Done
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Wed 23 Jun 2021 04:01:20 PM UTC, comment #2: 

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

Chet Ramey <chet>
Project Administrator
Fri 21 May 2021 08:39:32 PM UTC, comment #1: 

like ksh93 or when using an immediate value in bash, example:
`{ :;} 5<>file`

Olecya <nezabudka>
Fri 21 May 2021 07:35:32 PM UTC, original submission:  

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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by nezabudka (Posted a comment)
  • -email is unavailable- added by nezabudka (Voted in favor of this item)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-23 chet StatusNone => Done
    2021-05-21 nezabudka Carbon-Copy- => Added nezabudka

    Back to the top


    Powered by Savane 3.9