On 8/19/23 1:37 PM, jleivent wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Using exec to close a file descriptor in a variable crashes
bash. It doesn't matter how the fd got into the variable, but
the likely usage is with the {varname} form, as illustrated
below. I think what is happening is that the exec arg is being
parsed as a target to execute instead of a fd redirection,
Correct. The
exec "${foo}"<&-
isn't a valid way to express it, in the same way that \2<&- doesn't
recognize the `2' as part of the redirection. The file descriptor and
redirection operator can't have any quoted portions. (Using the ${foo} or
$foo isn't a valid way to do it, either, since the file descriptor part of
the redirection has to be a number, unless you use the {ident} extension
as in your first command.)
because when executed in two levels of shell (to allow the
inner one to crash while leaving the outer), it generates the
following error message:
bash: exec: 10: not found
Yes, this is the indicator that that `10' isn't part of the redirection.
But even that shouldn't cause the shell to terminate if the
target isn't found, so maybe this is two bugs?
It doesn't terminate, per se. It successfully closes stdin and goes on,
as Greg noted. Since stdin is where an interactive shell is reading its
input, the subsequent read failure causes the shell to exit.
Also note that the quoting and {} around foo in the last line
don't impact the bug.
True, see above.
This bug makes it difficult to use {varname} forms for file
descriptors, as it means there is no easy way to close them
before script exit.
Not true. `exec {foo}<&-' works fine.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
