On Fri, Jan 25, 2019 at 11:22:07AM -0400, Brad Spencer wrote: (...) > 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.
I can reproduce the problem, my bash is: GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu) | dualbus@system76-pc:~$ rm x | dualbus@system76-pc:~$ bash -c 'trap "echo WORKS" EXIT && touch x' | dualbus@system76-pc:~$ ls -l x | -rw-r--r-- 1 dualbus dualbus 0 Jan 25 08:26 x > Is this a bug? If not, can someone explain why the last command behaves > differently? I think it is a bug. My guess is that bash is optimizing the fork, and it's forgetting to run the `EXIT' trap in that case, or at least that seems to be the problem when I run this through a debugger. | dualbus@system76-pc:~/src/gnu/build-bash-devel$ gdb --args ./bash -c 'trap "echo WORKS" EXIT && touch x' | GNU gdb (Debian 8.2-1) 8.2 | (...) | (gdb) b execute_cmd.c:4537 | Breakpoint 1 at 0x515d2: file ../bash/execute_cmd.c, line 4537. | (gdb) r | Starting program: /home/dualbus/src/gnu/build-bash-devel/bash -c trap\ \"echo\ WORKS\"\ EXIT\ \&\&\ touch\ x | | Breakpoint 1, execute_simple_command (simple_command=0x555555761a48, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x5555557619a8) at ../bash/execute_cmd.c:4537 | 4537 execute_from_filesystem: | (gdb) p *simple_command->words->word | $1 = {word = 0x555555761908 "touch", flags = 0} | (gdb) n | 4538 if (command_line == 0) | (gdb) | 4539 command_line = savestring (the_printed_command_except_trap ? the_printed_command_except_trap : ""); | (gdb) | 4545 if (already_forked == 0 && (simple_command->flags & CMD_NO_FORK) && fifos_pending() > 0) | (gdb) | 4548 result = execute_disk_command (words, simple_command->redirects, command_line, | (gdb) | process 26087 is executing new program: /bin/touch | | [1]+ Stopped gdb --args ./bash -c 'trap "echo WORKS" EXIT && touch x'