From: Jilles Tjoelker <jilles@stack.nl>
To: Marc Glisse <marc.glisse@inria.fr>
Cc: Herbert Xu <herbert@gondor.apana.org.au>, dash@vger.kernel.org
Subject: Re: wait and ctrl+Z
Date: Fri, 4 May 2012 00:46:38 +0200 [thread overview]
Message-ID: <20120503224638.GA67644@stack.nl> (raw)
In-Reply-To: <alpine.DEB.2.02.1205040022560.2988@laptop-mg.saclay.inria.fr>
On Fri, May 04, 2012 at 12:28:17AM +0200, Marc Glisse wrote:
> On Fri, 4 May 2012, Herbert Xu wrote:
> > Marc Glisse <marc.glisse@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
prev parent reply other threads:[~2012-05-03 22:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 11:31 wait and ctrl+Z Marc Glisse
2012-05-03 21:51 ` Herbert Xu
2012-05-03 22:28 ` Marc Glisse
2012-05-03 22:46 ` Jilles Tjoelker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120503224638.GA67644@stack.nl \
--to=jilles@stack.nl \
--cc=dash@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=marc.glisse@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox