DASH Shell discussions
 help / color / mirror / Atom feed
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

      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