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

[George]

On Fri, 2017-05-19 at 21:38 -0500, Eduardo Bustamante wrote:
> On Fri, May 19, 2017 at 3:32 PM,  <tetsujin@scope-eye.net> wrote:
> [...]
> > 
> > I'd really like to see Bash get on the right side of this issue - and
> > the sooner the better.
> There is no right side. Only two opposing viewpoints. I don't think
> it's enough to justify the change breaking backwards compatibility.
Well, that's not how I see it. It's more like one viewpoint that makes sense, 
and one that doesn't. One that's consistent with how other file
redirections work, and one that's not. One that works the same as other shells 
that implement the same feature, and one that's not. One viewpoint
saying "Let's fix this bug because it's been around for a few years" and one 
saying "Let's preserve this bug because it's been around for a few years"
This behavior breaks a fundamental rule of how file redirections work: a file 
redirection only affects the job the redirection is attached to.
Ordinarily the only exception to this is "exec": redirecting "exec" has become 
the de-facto way of opening and closing files in the shell. Ordinarily
using exec is *THE ONLY* case where a redirection applies to something other 
than the command it's attached to.
And I don't think there's much risk of breaking backward compatibility here:
- First, it's a relatively recent feature (came in around 2009 or so)
- Second, it's much more commonly used with "exec" to open a file in the shell
- Third, frankly, I think it'd be awfully easy upon seeing this behavior for 
the first time, to just think it's broken and steer clear.
I mean, if you try this:
$ cmd --use-fd "$new_fd" {new_fd}<some_file
That doesn't work, because the command argument taken from "$new_fd" is 
resolved *before* the variable is populated with the dynamically assigned file
descriptor. So I think the likely scenario for most people who stumble upon 
this is to walk away scratching their heads, wondering why it didn't work
- and maybe they notice that the file descriptors stayed open in the shell - 
flatly contradicting the *most fundamental* rules of how file
redirections work for *anything* but "exec". And imagine their surprise when 
they learn it's a "feature"!
To really get any value out of it requires this:
$ { cmd --use-fd "$new_fd"; } {new_fd}<some_file
...Which is useful because $new_fd is populated and accessible to the command 
being run.
I think usually that's what people want when they try this: they want the file 
descriptor *and* the variable available to the command they're running,
but otherwise it's a normal redirection. And it's a relatively rare case 
because most redirections are to stdin/stdout/stderr - most commands don't
even know what to do with other file descriptors they inherit.