On 1/25/19 10:22 AM, Brad Spencer wrote:
> Consider the following commands:
>
> bash -c 'trap "echo WORKS" EXIT; touch x'
> (trap "echo WORKS" EXIT; touch x)
> (trap "echo WORKS" EXIT && touch x)
> bash -c 'trap "echo WORKS" EXIT; true'
> bash -c 'trap "echo WORKS" EXIT; false'
> bash -c 'trap "echo WORKS" EXIT; touch x && a'
> bash -c 'trap "echo WORKS" EXIT; touch x; a'
>
> They all produce the output "WORKS" as the trap runs on exit. (Where "a"
> is not a command or in the path and produces an error.)
>
> Now consider this command:
>
> bash -c 'trap "echo WORKS" EXIT && touch x'
>
> On newer versions of bash, it produces no output. Substituting different
> commands in the trap or tracing it seems to indicate that the trap never runs.
It's a case of bash being too aggressive optimizing the last command in
the AND_OR list. Here's a patch that disables that optimization attempt
while I look at alternatives.
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/
*** ../bash-5.0-patched/builtins/evalstring.c 2018-12-26 11:19:21.000000000
-0500
--- builtins/evalstring.c 2019-01-25 14:11:35.000000000 -0500
***************
*** 413,418 ****
--- 413,420 ----
command->value.Simple->flags |= CMD_NO_FORK;
}
+ #if 0
else if (command->type == cm_connection)
optimize_fork (command);
+ #endif
#endif /* ONESHOT */
