Re: using exec to close a fd in a var crashes bash

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}

Re: using exec to close a fd in a var crashes bash

On 8/20/23 12:15 AM, Grisha Levit wrote: exec {foo}>/tmp/foo exec "${foo}"<&- Looks like bash doesn't undo redirections if the exec fails -- so the shell terminates because the redirection closed stdin. I agree it would probably make sense to undo them if the exec fails and

Re: !& error

On 8/20/23 6:49 PM, Grisha Levit wrote: Sorry if it was premature. Btw I'm not sure about the fix for this in https://git.savannah.gnu.org/cgit/bash.git/diff/execute_cmd.c?h=devel&id=b64a7d8c Running `! &' stil

Re: SLA Information

On 8/18/23 2:27 PM, Malena Arduino via Bug reports for the GNU Bourne Again SHell wrote: To whom it may concern, I am working on creating an SLA for my company and was hoping to gain some clarity on your support for GNU Bash. If you could please provide me insight on the following items: As

read -E with read -d in completion function

The new read -E option is a nice addition. I think it's not unreasonable for a completion function to itself invoke `read' (with a file or pipe as input, not a tty) and this mostly works out fine, unless the -d option is used since the builtin stores the delimiter arg in a static variable: $ f() {

Re: using exec to close a fd in a var crashes bash

On Sun, 20 Aug 2023, 14:15 Grisha Levit, wrote: > [...] it would probably make sense to undo them if the exec fails and the > shell is not going to exit. > Just one question: how? The sequence of dup2() and close() calls has to occur before the execve() call. Whilst they could be undone by usin