Geoff Clare <g...@opengroup.org> wrote, on 17 Jul 2019: > > For foreground jobs, shells differ: > > Ksh93 has it as an AND-OR list: > > $ sleep 3 && sleep 4 > ^Z[1] + Stopped sleep 3 && sleep 4 > $ jobs > [1] + Stopped sleep 3 && sleep 4 > > Bash does not: > > $ sleep 3 && sleep 4 > ^Z > [1]+ Stopped sleep 3 > $ jobs > [1]+ Stopped sleep 3
It seems that bash has a rather nasty bug here, as can be seen in the following: $ sleep 5 || true && echo foo ^Z [1]+ Stopped(SIGTSTP) sleep 5 foo $ fg sleep 5 When the sleep 5 was stopped, bash treated this as completion of that pipeline (with non-zero "exit" status) and it went ahead and executed the remainder of the AND-OR list at that point, resulting in the "foo" output. Obviously what it should have done is delay processing the remainder of the AND-OR list until after the sleep had terminated (which was a couple of seconds after I typed "fg"). This was tested in bash 4.4.12 - perhaps someone who has bash 5 can check whether it still does the same. It may be that the fix for this is a simple matter of handling the WIFSTOPPED wait status differently, but if it should happen that the way Chet decides to fix it is to switch to treating the whole AND-OR list as one job, that would simplify the changes needed in the standard. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
