Hi Martin, thank you for your response.
On Fri, Feb 10, 2023 at 1:20 PM Martin Schulte <g...@schrader-schulte.de> wrote: > Hi Godmar! > > > For instance: > > > > gback@lat2022:~$ sleep 10 && echo yes > > ^Z > > [1]+ Stopped sleep 10 > > gback@lat2022:~$ fg > > sleep 10 > > gback@lat2022:~$ > > > > ... > > > > What's the rationale for bash's behavior in this case and is this > something > > that should be changed? > > I assume this is because sleep "exits" with an exit status of 148 > (=128+SIGTSTP) when it is stopped. If you replace the && with an ;, you get > "yes" immediately after pressing ^Z. > > So this is a bug, then, perhaps due to a shortcoming in the implementation that prevents it from storing and resuming the evaluation context within the currently evaluated boolean expression across stops/continuations? It appears to be mistaking the wait status for the exit status if your hypothesis is correct. This would mean that it may be accessing the wait status returned from `waitpid()` or similar in raw form (status != 0), without using proper `WIFSTOPPED`/`WIFEXITED` macros to predicate that test. That in turn seems unlikely, so maybe it's `if (WIFEXITED() && WEXITSTATUS() == 0) ... success else failure` which would apply in the job control case. - Godmar
