Re: $? and suspended jobs

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 21, 2014 12:58 PM, "Stephane Chazelas" <stephane.chazelas@xxxxxxxxx>
wrote:
>
> ~$ sleep 4; echo $?, $pipestatus
> ^Z
> zsh: suspended  sleep 4
> 20, 0
>
>
> Why not 128+20 = 148? I'd expect $pipestatus to contain the same
> value as $?

The values in the $pipestatus array are only updated when a process
completes, and a stopped job hasn't completed yet.  (I'm reporting a fact
here, not stating opinion on whether it should be this way.)

As for $?, as best I can tell the WIFSIGNALED() test returns false for the
exit status of a stopped job, so zsh doesn't add 128 to the status, but it
does apply the WEXITSTATUS() filter which removes the WIFSTOPPED() bits
leaving just the signal number.  This is, at least, incompatible with bash.

>
> ~$ {sleep 5; echo $?}
> ^Zzsh: suspended  { sleep 5; echo $?; }
> (20)1~$ fg
> [1]  + continued  { sleep 5; echo $?; }
> 20
>
> (that "(20)" is $? in my prompt). Here `echo $?` is run after sleep
> finishing and returning a 0 exit status. Still $? is always
> based on SIGTSTP.

Sleep is weird because it doesn't resume sleeping after being TSTP'd, it
just exits when CONT'd.  Also in that case you aren't just stopping sleep,
you're stopping the entire brace expression, which forces it to transform
from a current-shell job into a subshell. Hence there's a race and you
can't actually be sure that $? was set after sleep resumed.

Adding more layers of parens and braces just makes the order of events even
less predictable.