> 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
