> On 1/27/16 1:18 PM, Mathieu Patenaude wrote:
> >
> > When using "named" file descriptors inside a function, the file descriptors
> > are not automatically un-linked when the function returns, but when using
> > regular "numbered" file descriptors they are automatically "destroyed".
>
> Yes. That's the intent. The idea is that if you assign a variable, you
> have a `handle' on the file descriptor and can manage it yourself.
In other words, the file redirection persists because the variable persists...
But what if that weren't the case? What if, instead, the rule were "the
variable binding doesn't persist because the file redirection doesn't
persist"?
Perhaps that could be used to do things like this:
$ xterm -Sblah/$p {p}<>ttyfile
In other words, in this hypothetical case the value $p is made available to
perform substitutions in the command it's being applied to, and both the
variable $p an the file descriptor it represents are limited in scope to this
one command, as if running something like this:
$ ( exec {p}<>ttyfile; export p; xterm -Sblah/$p )
Personally, I don't think it makes sense for a redirection on a command to
persist beyond the scope of that command. A redirection with a dynamically-
assigned fd is basically equivalent to a redirection to a numbered fd. The two
should behave similarly.
---GEC
