and lists and suspended processes

and lists and suspended processes

[Clint Adams]

Should zsh wait for a suspended process to exit before continuing along
the sublist?

----- Forwarded message from Branden Robinson <branden@debian.org> -----

Things like:

foo && bar && baz

are a basic POSIX shell feature, and Bash doesn't handle them right.

Try:

echo one && sleep 10 && echo two

While, in the sleep, background the command with CTRL-Z.

The 'echo two' will run immediately.  This is wrong.  The sleep has no exit
status yet because it has not exited, and the && and || connectives must
only be evaluated once the preceding command has exited.  Until then, the
command in question *has* no exit status.  The box with Schroedinger's Cat
in it has not yet been opened.

ash, dash, pdksh, and zsh are also buggy, but instead they never run "echo
two" at all.  It appears that of Debian's allegedly POSIX-compliant shells
have this problem, except for posh.

Here are some speculations/argument from #debian-devel as to what may be
going on:

08:42PM|<asuffield> Overfiend: what you have in bash is bloody broken
   conditionals. I can't see how to fix it, and I can't stand looking
   at bash any longer to figure it out
08:42PM|<asuffield> it passes WUNTRACED to wait() when job control is
   enabled, so that it can spot jobs which have been sent SIGSTOP
08:43PM|<asuffield> somewhere in the pipeline logic is a missing check
   for WIFSTOPPED on the status code, to see if the process is really
   dead yet or not
08:49PM|<asuffield> look, WSTOPCODE() and WEXITCODE() are the same
   macro. zsh is calling WEXITCODE() and treating it as the exit code,
   and this is *INCORRECT*, because WIFEXITED() is false and WIFSTOPPED()
   is true
08:51PM|<Keybuk> and zsh documents that it won't continue a pipeline if
   the process is terminated by an unhandled signal
08:52PM|<Keybuk> so zsh is being correct, just different to bash
08:52PM|<asuffield> zsh has incorrectly interpreted the result from wait()
   as if the process had been terminated
08:52PM|<asuffield> the process has been stopped. this is a different
   event

Re: and lists and suspended processes

[Bart Schaefer]

On Sun, 2 Jan 2005, Clint Adams wrote:

> Should zsh wait for a suspended process to exit before continuing along
> the sublist?

I believe I was involved in a related discussion not that long ago.  
Trouble is, I can't recall if it was on zsh-workers or austin-group or 
somewhere else, and searching the zsh archives isn't helping me.

The short answer is, no, zsh can't wait for the suspended process to exit.

Given "one && two && three", if "two" stops, the shell has three choices:
(1) pretend the command was "{ one && two && three }" and suspend the 
    entire sublist; or
(2) pretend that "two" has returned a status and continue the junction; or
(3) stop the entire shell until "two" is resumed.

Choice (1) is undesirable because it subverts the user's intent (if he 
meant there to be braces, he should have typed them) and it puts "three" 
into a separate process when it might better have been run in the current 
shell.  Choice (3) is impossible in an interactive shell.  That leaves 
(2), which is what zsh does, using the signal number as the status.

If there's a bug, it's that zsh returns $? == 20 rather than $? == 148.
I forget why that's done -- maybe it's a compromise because $? > 127 would
indicate the signal caused the child to exit, which is not the case here.