Re: EXIT trap is not executed after an exec failure in a non-interactive shell

>I'll look at changing that Thank you. I agree, making traps behave the same after an exec failure as after any other failed builtin is a better course of action. It will make the trap facility stronger. execve failures are not that uncommon, and are hard to predict in advance. execve(2) man pa

Re: declare does not always set variable flags prior to assignment

On 10/4/21 10:17 AM, Léa Gris wrote: Found out that the declare statement does not properly set all variable flags before assign values: unset arr declare -i -a arr=(1 2 3) declare -p arr declare -ai arr=([0]="1" [1]="2" [2]="3") this is ok declare +i -a arr=(hello world) declare -p arr d

Re: Misleading error when attempting to run foreign executable

On 10/4/21 10:06 AM, Ilkka Virta wrote: On Mon, Oct 4, 2021 at 4:46 PM Chet Ramey > wrote: Bash reports the error it gets back from execve. In this case, it's probably that the loader specified for the executable isn't present on your system. OTOH, for a

Re: EXIT trap is not executed after an exec failure in a non-interactive shell

On 10/1/21 2:16 PM, Mark March wrote: Ok, thank you for clarifying. There is nothing in the documentation about this behavior as far as I can tell. I would suggest adding a line about traps getting reset after a failed exec to the paragraph on 'execfail'. I think it will be a cleaner fix, and

Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'

On 10/6/21 10:47 PM, Koichi Murase wrote: I'd like the default behavior to be closer to what it is when assoc_expand_once is enabled, as I said back in March. I think it's going to be better for users in the long run. Does that mean the behavior with `assoc_expand_once' being disabled also modi