Re: Leak in BASH "named" file descriptors?

[George]

> On 4/13/16 1:54 AM, George Caswell wrote:

> > 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.
>
> Then why have it?  There's not enough value in making a construct that
> is slightly different but functionally equivalent available unless it
> provides something new.

When paired with "exec" it does provide something new: dynamic file descriptor 
allocation. This is the primary use case, and it helps make the code
legible and correct as the number of open files in the script grows.

When paired with another command, it's not as useful, because probably the set 
of file descriptors you care about for a single command is much smaller than 
the set of all file descriptors known to the shell. It's less likely you'll 
need dynamic fd allocation in that case. As it stands this use case mainly 
exists to keep the syntax consistent: You can use it with "exec" so you can use 
it with other commands, too. Otherwise I don't think there's any benefit to it 
in bash, ksh, or zsh at present.


But that's why I suggested a way that I think would make it consistent AND 
useful: Make the variable binding accessible when the command string is 
processed, and export it to the command's environment when it is run (assuming 
it's not an array member or something): That way you can use the feature to 
inform the command of where that file descriptor is and what it's for. Most 
commands, if you hand them an extra file descriptor or two, won't know what to 
do with it, or even bother to find out that it's there. They'll just leave it 
open, ignorant of the fact that it is open. Usually if a command knows how to 
use a file descriptor that's already open when it starts running, it has to be 
told about it via command-line arguments.

(As a side note: IMO this is also a good reason why commands shouldn't get file 
descriptors (other than 0,1,2) from the shell unless they're explicitly 
connected via redirection syntax. Most processes will just be ignorant of the 
extra file descriptors, and so the end result will be that the process will 
keep the file descriptor open for its lifetime)


So in that case the value isn't so much the dynamic allocation aspect as the 
fact that it maybe makes the shell code a bit cleaner: reinforces the 
relationship between the redirection and the command line argument that 
provides the file descriptor number to the command:

$ command --log-fd=9 --run-job 9>./logfile

versus

$ command --log-fd=${log_fd} --run-job {log_fd}>./logfile


Not a lot of commands support this kind of thing, but for the ones that do, it 
could be useful. Much more useful IMO than the radical departure from normal 
redirection rules that happens now. And it makes the meaning of the two forms 
align nicely:

Using "exec 7<file" makes the file available to the shell on FD 7
Using "command 7<file" makes the file available to the command on FD 7
Using "exec {fd}<file" makes the file and $fd available to the shell
Using "command {fd}<file" makes the file and $fd available to the command

versus the present state in Bash:

Using "exec 7<file" makes the file available to the shell on FD 7
Using "command 7<file" makes the file available to the command on FD 7
Using "exec {fd}<file" makes the file and $fd available to the shell
Using "command {fd}<file" makes the file available to the shell and the command 
and makes $fd available to the shell after the command runs

or ksh:
...
Using "command {fd}<file" makes the file available to the command and makes $fd 
available to the shell after the command runs


---GEC