Re: {varname} redirection for a command or group leaves the file open

[tetsujin]

        > On Wed, May 10, 2017 at 8:52 PM, Pierre Gaston <address@hidden>
wrote: 

 > >_ See:_ 
 > >_
https://lists.gnu.org/archive/html/bug-bash/2012-11/msg00040.html[https://lists.gnu.org/archive/html/bug-bash/2012-11/msg00040.html
[1]]_ 
 > >_ Pierre_ 
 > >_ PS: I'm with you ;)_ 
 > 
 > Thanks for the link, I didn't find it in my earlier searches. 
 > 
 > Well, that's disappointing. So there is no technical reason for
this behavior 
 > other than copying the behavior of ksh. BTW zsh does the right
thing and in the 
 > following scenario: 
 > 
 > ls -lh /proc/self/fd {fd}>/dev/null 
 > 
 > and it closes the file descriptor after the command has completed.

Korn shell does the right thing as well:

$ { ls -l /proc/self/$fd; } {fd}</etc/passwd
lr-x------. 1 onelink onelink 64 May 19 14:52 /dev/fd/11 ->
/etc/passwd
# $fd is set within the {} block, and the file is open within the
block

$ echo $fd
11
# $fd is still set...

$ ls -l /proc/self/fd/$fd
ls: cannot access /proc/self/fd/11: No such file or directory
# but the file is not left open, because the redirection was specific
to that one command.

I really feel strongly that the way Bash handles this is just flat-out
wrong. It makes no sense relative to how other redirections work, and
I don't think it really suits the way the feature would be used in
practice.
And the way it's implemented is just shorthand for something we can
already do anyway:

In Bash, this:
cmd {fd}<file

Is equivalent to this:
exec {fd}<file
cmd

Rather than this (which is rather more useful):
exec {fd}<file # open file
cmd # job gets open file descriptor and a variable giving its number
exec {fd}<&- # close file - access to the file descriptor is limited
to the job

One of the arguments against this form working the same way as other
command redirections is that it's supposedly redundant. After all, you
could just redirect to a numeric FD:
{ cmd; } 5<file

But in terms of programming style "5" is a terrible way to refer to
something. It'd be nicer to give it a name:
{ input_fd=5; cmd; } 5<file

Of course, "5" is still being used in two places to refer (in a very
non-descriptive way) to the same entity. *THAT* in my opinion is where
auto-assigning redirect has the most value, it makes the relationship
much clearer:

{ cmd something something "$input_fd"; } {input_fd}<file

I'd really like to see Bash get on the right side of this issue - and
the sooner the better.


Links:
------
[1]
https://lists.gnu.org/archive/html/bug-bash/2012-11/msg00040.html%5Bhttps://lists.gnu.org/archive/html/bug-bash/2012-11/msg00040.html