|
From: | George Caswell |
Subject: | Re: Leak in BASH "named" file descriptors? |
Date: | Wed, 13 Apr 2016 01:54:50 -0400 |
> 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 |
[Prev in Thread] | Current Thread | [Next in Thread] |