On Fri, May 04, 2012 at 12:28:17AM +0200, Marc Glisse wrote:
On Fri, 4 May 2012, Herbert Xu wrote:
Marc Glisse marc.gli...@inria.fr wrote:
Hello,
I noticed a strange behavior of wait when I suspend and resume a script.
$ cat a.sh
#!/bin/dash
(sleep 7; echo blah)
(sleep 7; echo bloh)
wait ; echo coucou
$ ./a.sh
^Z
zsh: suspended ./a.sh
$ fg
[1] + continued ./a.sh
coucou
$ blah
bloh
As you can see, the instruction after wait was executed immediatly on
resume, without waiting for the jobs.
If I replace the ';' after wait by and do the same suspend+resume,
coucou is never printed.
I am using dash version 0.5.7-3 in debian testing.
That's normal as wait was interrupted by a signal. If you want
to wait even after an interruption, you should check the return
value of wait.
Hello, and thanks for you answer.
I find that quite surprising. I re-read the posix description of wait, and
my understanding is that the return value of wait should depend on what
happened to the waited process (exit code, signal), not to wait itself.
And other shells seem to agree.
This is not actually said in the XCU 'wait' page but in XCU 2.11 Signals
and Error Handling.
However, it says something subtly different: only a signal for which a
trap has been set should cause 'wait' to return immediately with an exit
status greater than 128.
Because no trap has been set on SIGTSTP, 'wait' should not be
interrupted here and the shell should continue waiting.
Likewise, if the shell internally uses SIGCHLD to get notified about
process termination, this does not interrupt 'wait'; dash implements
that aspect properly.
Are you suggesting that wait should always be used in a loop? With what
check exactly?
Only if you have set any traps that resume execution of the original
script (i.e. do not exit the process).
Otherwise, if 'wait' is being called without parameters, you can do
something like
until wait; do :; done
If 'wait' is being called with parameters, the required loop is very
complicated.
--
Jilles Tjoelker
--
To unsubscribe from this list: send the line unsubscribe dash in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
