Hi, the students in my Systems course are currently working on their shell assignment and of course are giving bash a spin to compare features. One student pointed out that logical expressions such as `a` && `b` in bash don't seem to work when `a` is stopped and resumed.
For instance: gback@lat2022:~$ sleep 10 && echo yes ^Z [1]+ Stopped sleep 10 gback@lat2022:~$ fg sleep 10 gback@lat2022:~$ `echo yes` appears to not execute, despite the fact that `sleep` exited with status 0/success. I verified with strace that `sleep` does not change its exit status in response to being stopped and resumed. Testing other shells, I found that csh, fish, and zsh have the same behavior as bash, but ksh will execute `echo` and print `yes` in this situation. When run in a subshell via (...) job control works as expected. I tried to find a relevant passage in the 2008 POSIX standard (the version I had handy), but it doesn't seem to address this situation specifically. Based on what it says, I would expect it to run the next command solely on the exit status of the first command, but bash somehow doesn't appear to do that when the first command was stopped and continued. This may be related to this discussion from 2014 on Interactive job control and looping constructs: https://lists.gnu.org/archive/html/bug-bash/2014-12/msg00160.html although this discussion doesn't mention && specifically. What's the rationale for bash's behavior in this case and is this something that should be changed? - Godmar
