Re: Logical expressions and job control

[Chet Ramey]

On 2/10/23 1:10 PM, Godmar Back wrote:
> 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.

I suppose it all depends on what you mean by `work' (and I can assure you
there are different interpretations here). If you send `a' a SIGTSTP, it
returns control to its parent and modifies $?.

For example:

$ sleep 10
^Z
[1]+  Stopped                 sleep 10
$ echo $?
146

So if you use $? as the determining factor for whether or not to execute
`b', you're obviously not going to run it.

Just about every shell except ksh93 does this. It's the collision of job
control, which is process (group) based, and an AND-OR list that consists
of multiple commands that can spawn multiple processes.

> 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.

You can add yash, dash, mksh, and the BSD shells (dash siblings) to the
`works like bash' list.

> When run in a subshell via (...) job control works as expected.

Because you force the command to be executed in a subshell that is stopped
as a unit when you send it SIGTSTP. There are various ways you can do this:

{ sleep 10 && echo yes; } & fg
sleep 10 && echo yes & fg

and so on.

> 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.

POSIX finally tackled the issue in

https://www.austingroupbugs.net/view.php?id=1254

and leaves this part explicitly unspecified.

> What's the rationale for bash's behavior in this case and is this something
> that should be changed?

The cause and rationale should be clear from the explanation above. Pretty
much every shell but ksh behaves like bash, so this is probably going to
stay as-is.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/