Re: SIGCHLD trap in a shell

2017-05-11 Thread Vincent Lefevre
On 2017-05-11 11:04:56 -0400, Chet Ramey wrote:
> Sigh. The message you responded to that prompted this sub-discussion was
> the one in which I asked about shell behavior when monitor mode is set in
> a non-interactive shell:
> 
> > I'm curious what you think the shell should do in this case. Remember
   
and "this case" was "if bash, then use 'set -m'":

"* With bash and posh, I get:
^
[...]
If I add "set -m", then bash behaves like [...]"


(I did not mention posh with "set -m", as it does not support it:
posh: set: -m: unknown option)

So, I think that you should have been clearer if you wanted the other
shells to be in monitor mode too.

> > that it doesn't get the SIGINT. Other shells seem to fake it and act
> > like they received a SIGINT, and abort the entire script. Should bash
> > stop the loop, should it kill itself with SIGINT, or should it continue?
> 
> Your response was as I quoted, and the thread went from there. But that's
> OK; I'm done with it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-05-11 Thread Chet Ramey
On 5/11/17 6:24 AM, Geoff Clare wrote:

> In this situation, the shell started as $SHELL *is* the foreground
> command, which is why it gets the SIGINT.  The process groups it
> creates to run date and sleep are background process groups.  This
> is because the shell you are typing "$SHELL -c ..." in is the
> controlling process for the terminal session, not the one started
> as $SHELL.

In practice, it doesn't work exactly that way.  When monitor mode is
enabled, and the shell knows it is the process group leader of the
foreground process group, it is permitted to give the process groups it
creates access to the terminal. Most shells do that.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-05-11 Thread Chet Ramey
On 5/11/17 5:54 AM, Vincent Lefevre wrote:

>> Using the following:
>>
>> $SHELL -c 'set -m; while true; do date; /bin/sleep 10; done; echo after'
>>
>> bash devel, ksh93, dash, mksh all break the loop, act as if the shell
>> received a SIGINT, and exit (the final `after' isn't printed).
> 
> I confirm for dash. I have not tried bash devel. But this is not what
> I observe with ksh93 and mksh (under Debian/unstable):

That's the wonderful thing about ksh93: having so many different versions
to choose from.

$ ksh93 -c 'echo ${.sh.version}'
Version AIJM 93v- 2013-10-08
$ ksh93 -c 'set -m; while true; do date; /bin/sleep 10; done ; echo after loop'
Thu May 11 10:25:55 EDT 2017
^C
$


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-05-11 Thread Vincent Lefevre
On 2017-05-11 11:24:54 +0100, Geoff Clare wrote:
> Vincent Lefevre  wrote, on 11 May 2017:
> >
> > > What if the shell is not executing a loop? Given
> > > 
> > > $SHELL -c 'set -m; date ; /bin/sleep 10; date'
> > > 
> > > all the shells I tested -- execept bash-4.4, which is where we started --
> > > kill the shell if the sleep dies due to a SIGINT.  Again, zsh, and mksh
> > > as well this time, wait 10 seconds before killing the shell.
> >  ^^^
> > 
> > More precisely, wait for the sleep command to terminate (these
> > 10 seconds corresponds to its argument), i.e. the "sleep" doesn't
> > react to Ctrl-C. But a kill -INT kills it. So, it seems that only
> > the shell receives the SIGINT from a Ctrl-C, but takes it into
> > account only after the current foreground command has terminated.
> 
> In this situation, the shell started as $SHELL *is* the foreground
> command, which is why it gets the SIGINT.  The process groups it
> creates to run date and sleep are background process groups.  This
> is because the shell you are typing "$SHELL -c ..." in is the
> controlling process for the terminal session, not the one started
> as $SHELL.

If I understand correctly, it is a choice of implementation to
decide which process group should be the foreground one, which
is why bash 4.4 and mksh have opposite behaviors.

But then I don't understand why they behave in the same way here:

$ mksh -c 'set -m; cat; true'

$ bash -c 'set -m; cat; true'

In both cases, "cat" reads from the terminal. However, POSIX says
(page 3494, line 118121):

|If a background job attempts to access the login terminal
|(controlling terminal), it is stopped by the terminal driver and
|the shell is notified, which, in turn, notifies the user. [...]

So, in the mksh case, if "cat" is in a background process group
(as you said above), i.e. a background job (according to the
definition 3.35), then one would expect it to be stopped.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-05-11 Thread Robert Elz
Date:Thu, 11 May 2017 11:14:13 +0200
From:Vincent Lefevre 
Message-ID:  <20170511091413.ga17...@zira.vinc17.org>

  | I agree, but SIGCHLD could still be useful to know that at least
  | a process has terminated, and that "wait" should be used to know
  | more.

Only if you only have one child process.   If there are any more than
that you risk either waiting for the wrong one, or you have to wait
for everything.

  | It seems that the only thing that is really missing in bash's wait is
  | the equivalent of WNOHANG.

That, and a way to find out which process just exited.

kre

ps: this is not the right place to attempt to debug zsh job control
peculiarities.




Re: SIGCHLD trap in a shell

2017-05-11 Thread Geoff Clare
Vincent Lefevre  wrote, on 11 May 2017:
>
> > What if the shell is not executing a loop? Given
> > 
> > $SHELL -c 'set -m; date ; /bin/sleep 10; date'
> > 
> > all the shells I tested -- execept bash-4.4, which is where we started --
> > kill the shell if the sleep dies due to a SIGINT.  Again, zsh, and mksh
> > as well this time, wait 10 seconds before killing the shell.
>  ^^^
> 
> More precisely, wait for the sleep command to terminate (these
> 10 seconds corresponds to its argument), i.e. the "sleep" doesn't
> react to Ctrl-C. But a kill -INT kills it. So, it seems that only
> the shell receives the SIGINT from a Ctrl-C, but takes it into
> account only after the current foreground command has terminated.

In this situation, the shell started as $SHELL *is* the foreground
command, which is why it gets the SIGINT.  The process groups it
creates to run date and sleep are background process groups.  This
is because the shell you are typing "$SHELL -c ..." in is the
controlling process for the terminal session, not the one started
as $SHELL.

This is in contrast to the normal case where $SHELL is the controlling
process, in which case the date and sleep commands would be in the
foreground and they would receive SIGINT but the shell would not.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England



Re: SIGCHLD trap in a shell

2017-05-11 Thread Vincent Lefevre
On 2017-05-10 09:56:58 -0400, Chet Ramey wrote:
> On 5/10/17 8:07 AM, Vincent Lefevre wrote:
> > ksh93 does (isn't this a bug?), but not zsh. With
> > 
> >   zsh -c 'while true; do date; /bin/sleep 100; done'
> > 
> > a kill -INT on the sleep process kills only this process, not the
> > shell, while Ctrl-C kills both.
> 
> OK. That's not quite what we're discussing here, but close. In the ^C
> case here, the shell gets the SIGINT and has to decide whether or not to
> `honor' it. Most shells base that decision on whether or not the foreground
> process dies due to SIGINT, and zsh is no different in that regard.  In
> the manual SIGINT case, ksh93 is the only shell that kills the shell when
> the sleep dies due to SIGINT. The other shells I tested (bash devel,
> bash-4.4, dash, mksh) behave as zsh does.
> 
> It's the behavior of monitor mode in a non-interactive shell we're talking
> about.

Well, not exactly. In zsh, monitor mode is useless if the goal is
to have information on the number of running background processes.
So, one can choose to enable it or not, depending on drawbacks
concerning Ctrl-C / SIGINT, for instance.

> Using the following:
> 
> $SHELL -c 'set -m; while true; do date; /bin/sleep 10; done; echo after'
> 
> bash devel, ksh93, dash, mksh all break the loop, act as if the shell
> received a SIGINT, and exit (the final `after' isn't printed).

I confirm for dash. I have not tried bash devel. But this is not what
I observe with ksh93 and mksh (under Debian/unstable):

$ ksh93 -c 'set -m; while true; do date; /bin/sleep 10; done; echo after'
Thu May 11 11:28:53 CEST 2017
[1] + Stopped (tty output)   ksh93 -c "set -m; while true; do date; 
/bin/sleep 10; done; echo after"
$ fg
ksh93 -c "set -m; while true; do date; /bin/sleep 10; done; echo after"
[1] + Stopped (tty output)   ksh93 -c "set -m; while true; do date; 
/bin/sleep 10; done; echo after"

and so on. The problem seems to be when an external command
terminates. For instance, with

$ ksh93 -c 'set -m; while true; do /bin/true; /bin/true; /bin/sleep 10; done; 
echo after'

I need to type fg twice before the sleep gets executed. And Ctrl-C
doesn't have any effect.

With mksh, a Ctrl-C doesn't interrupt the sleep; it is just taken
into account after the 10 seconds of the sleep... like with zsh:

> zsh (5.2 if that makes a difference) waits 10 seconds (?) and then
> does the same. So that takes care of the loop behavior.

Ditto.

> What if the shell is not executing a loop? Given
> 
> $SHELL -c 'set -m; date ; /bin/sleep 10; date'
> 
> all the shells I tested -- execept bash-4.4, which is where we started --
> kill the shell if the sleep dies due to a SIGINT.  Again, zsh, and mksh
> as well this time, wait 10 seconds before killing the shell.
 ^^^

More precisely, wait for the sleep command to terminate (these
10 seconds corresponds to its argument), i.e. the "sleep" doesn't
react to Ctrl-C. But a kill -INT kills it. So, it seems that only
the shell receives the SIGINT from a Ctrl-C, but takes it into
account only after the current foreground command has terminated.

I observe the same behavior as with the loop (this is consistent).
So, here, this corresponds to what you observed, except for ksh93.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-05-11 Thread Vincent Lefevre
On 2017-05-10 20:32:41 +0700, Robert Elz wrote:
> Date:Wed, 10 May 2017 14:44:43 +0200
> From:Vincent Lefevre 
> Message-ID:  <20170510124443.gd25...@cventin.lip.ens-lyon.fr>
> 
>   | But wouldn't it be useful to have the list of terminated processes as
>   | a new POSIX feature for shells?
> 
> Yes, it would, but I don't personally believe that SIGCHLD is the
> mechanism to use to achieve that.   The issue is really that the
> shell's wait command hasn't kept up with the system call.

I agree, but SIGCHLD could still be useful to know that at least
a process has terminated, and that "wait" should be used to know
more.

[...]
> Some of what bash is doing might be providing the lead for some of
> this (some  of what they have I plan to copy, and then probably add
> a little more, and hope that perhaps others will copy...)

It seems that the only thing that is really missing in bash's wait is
the equivalent of WNOHANG.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-05-10 Thread SHwareSyst
Once the action is set, delivery should succeed, imo, for each child  that 
would normally have a separate process id due to creation of a child  
utility environment. I can see older Unix's that didn't track process  ids in 
sigevent structures, because they only implemented signal() and  raise(), might 
have multiple SIGCHLD queued that weren't  distinguishable from each other, 
but this no longer holds. For them reaping  multiple may have been 
considered conforming due to the lack of information.  Applications now have to 
take 
into account even when they set the handler using  signal(), the handler may 
be triggered by sigqueue() rather than raise(), so is  required to have 
distinguishing information when raise() is called also, at  least to the extent 
of different si_pid values. Conversely, raise() is required  to synthesize 
a siginfo_t structure if the handler is a sa_sigaction type  function. 
 
>From this a shell might reap multiple child stop / child start pairs  for a 
single child, and I'd hesitate to call that non-conforming, but I believe  
it should call the action at least once for each, and the child exit. An 
action  doesn't have access to the si_code member, so can't perform different 
actions  based on that, but when si_pid is the same and si_code differ that's 
enough to  keep it unreaped so the action is performed, iow. I feel where 
the standard  should be more explicit, for those interrupts that can have 
multiple si_code  values, is: what is the default si_code value when an 
application calls raise()  for that signo, and whether a handler set by 
signal() is 
only triggered when  sigqueue() has both that signo and si_code set. Do we 
need to reserve an si_code  value to mean that raise() was used so further 
information about reason for  the signal unavailable?
 
 
In a message dated 5/10/2017 9:15:56 A.M. Eastern Daylight Time,  
chet.ra...@case.edu writes:

On  5/10/17 8:47 AM, shwares...@aol.com wrote:
> Yes, reception can be  blocked for reasons outside a scripts control 
before
> an action is set  with trap, but the standard does speak to when signals 
are
> to be  raised and delivery attempted.

That's all the standard can guarantee.  The standard does not guarantee that
each child exit will generate a  separate SIGCHLD delivery.  There is also
nothing in the standard that  speaks to what a shell, for instance, does
when it receives a signal.   For instance, there is nothing preventing a
shell from reaping multiple  children when it receives a single SIGCHLD and
running a single instance of  the SIGCHLD trap as a result.

-- 
``The lyf so short, the craft so  long to lerne.'' - Chaucer
``Ars longa, vita  brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu 
http://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-05-10 Thread Chet Ramey
On 5/10/17 8:07 AM, Vincent Lefevre wrote:
> On 2017-04-27 08:50:23 -0400, Chet Ramey wrote:
>> On 4/26/17 8:07 PM, Vincent Lefevre wrote:
>>> It should kill itself with SIGINT to mimic what happens in an
>>> interactive shell. For instance, I expect
>>>
>>>   bash -c 'set -m; while true; do date; sleep 1; done'
>>>
>>> to behave like if
>>>
>>>   while true; do date; sleep 1; done
>>>
>>> were typed in an interactive bash.
>>>
>>> This seems much more useful.
>>
>> So fake the signal if you're in a loop.  That's not an unreasonable
>> position, but it's not quite what other shells do.  They seem to fake
>> the signal if the child process dies due to SIGINT, period.
> 
> ksh93 does (isn't this a bug?), but not zsh. With
> 
>   zsh -c 'while true; do date; /bin/sleep 100; done'
> 
> a kill -INT on the sleep process kills only this process, not the
> shell, while Ctrl-C kills both.

OK. That's not quite what we're discussing here, but close. In the ^C
case here, the shell gets the SIGINT and has to decide whether or not to
`honor' it. Most shells base that decision on whether or not the foreground
process dies due to SIGINT, and zsh is no different in that regard.  In
the manual SIGINT case, ksh93 is the only shell that kills the shell when
the sleep dies due to SIGINT. The other shells I tested (bash devel,
bash-4.4, dash, mksh) behave as zsh does.

It's the behavior of monitor mode in a non-interactive shell we're talking
about.  Using the following:

$SHELL -c 'set -m; while true; do date; /bin/sleep 10; done; echo after'

bash devel, ksh93, dash, mksh all break the loop, act as if the shell
received a SIGINT, and exit (the final `after' isn't printed). zsh (5.2
if that makes a difference) waits 10 seconds (?) and then does the same.
So that takes care of the loop behavior.

What if the shell is not executing a loop? Given

$SHELL -c 'set -m; date ; /bin/sleep 10; date'

all the shells I tested -- execept bash-4.4, which is where we started --
kill the shell if the sleep dies due to a SIGINT.  Again, zsh, and mksh
as well this time, wait 10 seconds before killing the shell.

This is what I said above: non-interactive shells in monitor mode fake
the signal if the foreground process dies due to SIGINT.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-05-10 Thread Robert Elz
Date:Wed, 10 May 2017 14:44:43 +0200
From:Vincent Lefevre 
Message-ID:  <20170510124443.gd25...@cventin.lip.ens-lyon.fr>

  | But wouldn't it be useful to have the list of terminated processes as
  | a new POSIX feature for shells?

Yes, it would, but I don't personally believe that SIGCHLD is the
mechanism to use to achieve that.   The issue is really that the
shell's wait command hasn't kept up with the system call.

The shells know what processes have exited, and their exit status,
there is just no standard way of communicating the info into the
script.   If wait were a little more flexible, and allowed waiting
for any process (like bash's does) and also returned the process
(and/or job) id of the process that exited, then the script would be
able to manage processes.

But while we have just "wait for this specific process, and hang
while doing it" or "wait for everything to finish, and hang while
doing it" there just is not enough info to accomplish much.
Even if we get a CHLD trap, there's no standard way to know which
(or even how many) process(es) exited to cause it.

But it is not the job of this group to invent some better interface.

Rather the implementors should be doing that, and then once there
appears a popular common solution, then it can be standardised.

Some of what bash is doing might be providing the lead for some of
this (some  of what they have I plan to copy, and then probably add
a little more, and hope that perhaps others will copy...)

kre




Re: SIGCHLD trap in a shell

2017-05-10 Thread Robert Elz
Date:Wed, 10 May 2017 14:35:28 +0200
From:Vincent Lefevre 
Message-ID:  <20170510123528.gc25...@cventin.lip.ens-lyon.fr>

  | Well, in any case, I meant that for
  | 
  |   `/path/to/external/command`
  | 
  | the SIGCHLD can either be due to the subshell or the external command

It is due to the subshell (if one is created, which it would be in that case.)
If the subshell decides to terminate itself by exec'ing some other process,
that's its business, but as far as the parent shell is concerned, it is the
subshell that has exited.

kre




Re: SIGCHLD trap in a shell

2017-05-10 Thread Joerg Schilling
Chet Ramey  wrote:

> That's all the standard can guarantee. The standard does not guarantee that
> each child exit will generate a separate SIGCHLD delivery.  There is also
> nothing in the standard that speaks to what a shell, for instance, does
> when it receives a signal.  For instance, there is nothing preventing a
> shell from reaping multiple children when it receives a single SIGCHLD and
> running a single instance of the SIGCHLD trap as a result.

On Solaris with a signal queue length of 32, is seems to be likely that this 
usually won't happen.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'



Re: SIGCHLD trap in a shell

2017-05-10 Thread Chet Ramey
On 5/10/17 8:47 AM, shwares...@aol.com wrote:
> Yes, reception can be blocked for reasons outside a scripts control before
> an action is set with trap, but the standard does speak to when signals are
> to be raised and delivery attempted.

That's all the standard can guarantee. The standard does not guarantee that
each child exit will generate a separate SIGCHLD delivery.  There is also
nothing in the standard that speaks to what a shell, for instance, does
when it receives a signal.  For instance, there is nothing preventing a
shell from reaping multiple children when it receives a single SIGCHLD and
running a single instance of the SIGCHLD trap as a result.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-05-10 Thread Chet Ramey
On 5/10/17 8:26 AM, Robert Elz wrote:

> Nothing, anywhere, says that the action for a CHLD trap will be executed
> once for every command the shell runs.

Not in the standard, but some shells (e.g., bash) make that guarantee.
You have to rely on what the shell provides.

> You absolutely cannot program scripts with any expectation of receiving
> CHLD traps.

Unless you are programming for a specific shell that assures it.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-05-10 Thread SHwareSyst
Yes, reception can be blocked for reasons outside a scripts control before  
an action is set with trap, but the standard does speak to when signals are 
 to be raised and delivery attempted. There is no blanket exception I see,  
if a regular utility is implemented as a built-in, that the system can 
forego  raising SIGCHLD when it exits so the shell, as parent process, doesn't 
see  a delivery attempt. At most a shell can bypass calling raise() or  
sigqueue() and queue the signal directly using internal routines for a  
built-in.
 
 
In a message dated 5/10/2017 8:26:59 A.M. Eastern Daylight Time,  
k...@munnari.oz.au writes:

Date:Wed, 10 May 2017 08:02:11  -0400
From: shwares...@aol.com
Message-ID:   <2557dd.2e673a3d.46445...@aol.com>


| Still, the  effects on the environment should be the same, as separate
| utility  or built-in, including signal generation...

No, Joerg is right -  nothing in the spec says when a SIGCHLD trap
is going to be received, it  just happens when the shell happens to
receive that signal.   And  the shell just happens to receive it
if a child has exited, when SIGCHLD  has been set to be caught, when
it is not blocked (for some shells, that  might never happen) and
the child hasn't already been waited  for.

Nothing, anywhere, says that the action for a CHLD trap will be  executed
once for every command the shell runs.

You absolutely  cannot program scripts with any expectation of receiving
CHLD  traps.

kre




Re: SIGCHLD trap in a shell

2017-05-10 Thread Vincent Lefevre
On 2017-05-10 19:26:10 +0700, Robert Elz wrote:
> You absolutely cannot program scripts with any expectation of
> receiving CHLD traps.

But wouldn't it be useful to have the list of terminated processes as
a new POSIX feature for shells? Something like what you mentioned at
the C level in another message:

|But for SIGCHLD, at C level, the general idea is that the handler waits
|with WNOHANG for as many processes as have exited (and retrieves status
|of each of them).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-05-10 Thread Vincent Lefevre
On 2017-05-10 13:43:44 +0200, Joerg Schilling wrote:
> Vincent Lefevre  wrote:
> 
> > On 2017-04-27 08:45:37 +0700, Robert Elz wrote:
> > > ps: the seq command in your example cannot (properly) have caused the
> > > SIGCHLD that you (think you) counted,
> >
> > Well, I assume that this depends on the shell. But for most shells (if
> > not all in practice), it is the seq command that causes the SIGCHLD.
> 
> Given that some shells implement more and more commands as builtins,
> I believe that the delivery of a SIGCHLD cannot be expected in
> general.

Well, in any case, I meant that for

  `/path/to/external/command`

the SIGCHLD can either be due to the subshell or the external command
(though this probably doesn't matter for the SIGCHLD signal itself).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-05-10 Thread Robert Elz
Date:Wed, 10 May 2017 08:02:11 -0400
From:shwares...@aol.com
Message-ID:  <2557dd.2e673a3d.46445...@aol.com>


  | Still, the effects on the environment should be the same, as separate
  | utility or built-in, including signal generation...

No, Joerg is right - nothing in the spec says when a SIGCHLD trap
is going to be received, it just happens when the shell happens to
receive that signal.   And the shell just happens to receive it
if a child has exited, when SIGCHLD has been set to be caught, when
it is not blocked (for some shells, that might never happen) and
the child hasn't already been waited for.

Nothing, anywhere, says that the action for a CHLD trap will be executed
once for every command the shell runs.

You absolutely cannot program scripts with any expectation of receiving
CHLD traps.

kre



Re: SIGCHLD trap in a shell

2017-05-10 Thread SHwareSyst
Still, the effects on the environment should be the same, as separate  
utility or built-in, including signal generation... Exceptions are for  the 
special built-ins the standard requires be part of the shell, when  documented 
that way, that I see.
 
 
In a message dated 5/10/2017 7:45:32 A.M. Eastern Daylight Time,  
joerg.schill...@fokus.fraunhofer.de writes:

Vincent  Lefevre  wrote:

> On 2017-04-27  08:45:37 +0700, Robert Elz wrote:
> > ps: the seq command in your  example cannot (properly) have caused the
> > SIGCHLD that you (think  you) counted,
>
> Well, I assume that this depends on the shell.  But for most shells (if
> not all in practice), it is the seq command  that causes the SIGCHLD.

Given that some shells implement more and more  commands as builtins, I 
believe 
that the delivery of a SIGCHLD cannot be  expected in general.

Jörg

-- 
EMail:jo...@schily.net   (home) Jörg  Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de  (work) Blog: 
http://schily.blogspot.com/
URL: http://cdrecord.org/private/  
http://sf.net/projects/schilytools/files/'




Re: SIGCHLD trap in a shell

2017-05-10 Thread Vincent Lefevre
On 2017-04-27 08:50:23 -0400, Chet Ramey wrote:
> On 4/26/17 8:07 PM, Vincent Lefevre wrote:
> > It should kill itself with SIGINT to mimic what happens in an
> > interactive shell. For instance, I expect
> > 
> >   bash -c 'set -m; while true; do date; sleep 1; done'
> > 
> > to behave like if
> > 
> >   while true; do date; sleep 1; done
> > 
> > were typed in an interactive bash.
> > 
> > This seems much more useful.
> 
> So fake the signal if you're in a loop.  That's not an unreasonable
> position, but it's not quite what other shells do.  They seem to fake
> the signal if the child process dies due to SIGINT, period.

ksh93 does (isn't this a bug?), but not zsh. With

  zsh -c 'while true; do date; /bin/sleep 100; done'

a kill -INT on the sleep process kills only this process, not the
shell, while Ctrl-C kills both.

(Note: the behavior is different with "set -m", but the point is
that there is no need for "set -m" to monitor background processes
with zsh.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-05-10 Thread Vincent Lefevre
On 2017-04-27 08:45:37 +0700, Robert Elz wrote:
> ps: the seq command in your example cannot (properly) have caused the
> SIGCHLD that you (think you) counted,

Well, I assume that this depends on the shell. But for most shells (if
not all in practice), it is the seq command that causes the SIGCHLD.

> as it is running in a sub-shell, and traps get reset there (and even
> if they didn't, that would update a different copy of the counter
> 'c')

In most shells, the subshell is replaced by the seq command with just
an execve, since it is the last command and there are no traps in the
subshell. I suppose that this is not forbidden by POSIX, i.e. with the
following example, getting the same value twice is not forbidden.

#!/bin/sh
echo `sh -c 'echo $PPID'; sh -c 'echo $$'`

> You can see that background processes do generate SIGCHLD with a
> script like...
> 
> c=0
> trap 'c=$((c + 1))' CHLD
> 
> while [ $c -lt 3 ]; do
> echo $c
> read junk
> sleep 0.5 &
> done

OK, I confirm.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-04-27 Thread Chet Ramey
On 4/26/17 7:57 PM, Vincent Lefevre wrote:
> On 2017-04-25 21:32:56 -0400, Chet Ramey wrote:
>> There is no requirement that a trap be executed each time a particular
>> signal is generated.  There is no requirement that the system keep a
>> count of instances of a particular pending signal; only that the signal
>> is pending.  SIGCHLD isn't different from any other signal in this
>> regard.
> 
> In such a case, how can you know the number of remaining processes?

You can't, really. There is no guarantee that the shell will receive
exactly one SIGCHLD for each child that exits, because there is no
requirement that the kernel queue signals.

It's easy to imagine the following scenario:

process blocks SIGCHLD
child exits, kernel adds SIGCHLD to pending signal mask
child exits, kernel adds SIGCHLD to pending signal mask
process unblocks SIGCHLD
kernel sends SIGCHLD to process

Even if the process only reaps one of the two available exited children,
the kernel is not going to re-deliver SIGCHLD. And virtually every shell
out there is going to reap as many exited processes as it can each time
it calls waitpid() or equivalent.

The best you can do as a script writer is rely on whatever guarantees the
shell gives you. Bash guarantees that a SIGCHLD trap will be called once
for each child that it reaps when job control is enabled, but Posix
doesn't.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-04-26 Thread Vincent Lefevre
On 2017-04-25 21:32:56 -0400, Chet Ramey wrote:
> There is no requirement that a trap be executed each time a particular
> signal is generated.  There is no requirement that the system keep a
> count of instances of a particular pending signal; only that the signal
> is pending.  SIGCHLD isn't different from any other signal in this
> regard.

In such a case, how can you know the number of remaining processes?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-04-26 Thread Chet Ramey
On 4/25/17 9:21 AM, Vincent Lefevre wrote:

> * With bash and posh, I get:
> 
> 0
> 0
> 0
> 0
> 0
> 0
> [...]
> 
> i.e. no trap executions at all.
> 
> If I add "set -m", then bash behaves like ash, etc., except that it
> no longer reacts to Ctrl-C (the Ctrl-C only interrupts the sleep).

I'm curious what you think the shell should do in this case. Remember
that it doesn't get the SIGINT. Other shells seem to fake it and act
like they received a SIGINT, and abort the entire script. Should bash
stop the loop, should it kill itself with SIGINT, or should it continue?

> Anyway, "set -m" is not supposed to be used in shell scripts (see
> rationale for the "set" built-in).

That's not quite what the rationale says.  The -m option is only required
if you support the UPE, but if you do, there's nothing that says scripts
can't or shouldn't use it.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-04-25 Thread Chet Ramey
On 4/25/17 9:15 PM, Vincent Lefevre wrote:
> On 2017-04-25 23:49:56 +0200, Jilles Tjoelker wrote:
>> On Tue, Apr 25, 2017 at 03:21:24PM +0200, Vincent Lefevre wrote:
>>> I wonder how the following script is supposed to behave.
>>
>>> The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says:
>>> "[...] a signal specified using a symbolic name, without the SIG prefix,
>>> as listed in the tables of signal names in the  header defined
>>> in XBD Headers"; there, SIGCHLD is listed as "Child process terminated,
>>> stopped, [XSI] or continued". From this spec, I would assume that the
>>> trap would be executed for any child process that terminates, stops, or
>>> continues. But this is not what I observe.
>>
>> I would not assume that. Since trap actions are not executed while
>> waiting for a foreground process to exit, it is likely that multiple
>> instances of SIGCHLD will be coalesced into a single trap action
>> execution.
> 
> IMHO, this would be a bug. A shell should be able to know when all
> its children have terminated. IMHO, all the pending traps should
> be executed before the next command.

There is no requirement that a trap be executed each time a particular
signal is generated.  There is no requirement that the system keep a
count of instances of a particular pending signal; only that the signal
is pending.  SIGCHLD isn't different from any other signal in this
regard.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: SIGCHLD trap in a shell

2017-04-25 Thread Vincent Lefevre
On 2017-04-26 06:12:25 +0700, Robert Elz wrote:
> Date:Tue, 25 Apr 2017 15:21:24 +0200
> From:Vincent Lefevre 
> Message-ID:  <20170425132124.ga7...@cventin.lip.ens-lyon.fr>
> 
> I see Jillles has said much the same thing while I was preparing
> this, but ...
> 
>   | I wonder how the following script is supposed to behave.
> 
> I wonder more if it has any expected behaviour.
> 
>   | I would assume that the
>   | trap would be executed for any child process that terminates, stops, or
>   | continues. But this is not what I observe.
> 
> I suspect here that your observations are (partly) incorrect.

Nope...

>   | 
>   | #!/bin/sh
>   | 
>   | n=${1:-30}
>   | n=$((n+0))
>   | 
>   | c=0
>   | trap 'c=$((c+1))' CHLD
>   | 
>   | for i in `seq $n`; do /bin/sleep 0.1 & done
>   | 
>   | while true
>   | do
>   |   echo $c
>   |   /bin/sleep 0.1
>   | done
>   | 
>   | 
>   | I call this script with:
>   | 
>   |
>   | 
>   | Under Debian unstable:
> 
>   | * With ash, dash, mksh and yash, I get:
> 
> With the NetBSD sh (which is an ash derivative) that is what I see too.
> 
>   | So, I get +1 only for commands that are not executed in background
>   | (asynchronously).
> 
> No, that does not fit with your observations. If that were true,m
> the first output value would be 0, as the exct is done before the
> first foreground sleep.

Wrong. The first trap comes from the seq command. This can be seen by
replacing `seq $n` with a fixed list: the first output value becomes 0.

> What is happening here is that all the background processes are created
> at about the same time, all run for very little time, and all will terminate
> at essentially the same time.  There's nothing that requires signals to be
> queued anywhere (though they may be).

No, replacing "/bin/sleep 0.1 &" with ":;" yields the same behavior.
So, the background processes don't trigger the trap (see also my
remark above, where one gets 0 even though there are background
processes).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-04-25 Thread Vincent Lefevre
On 2017-04-25 16:00:54 +0200, Joerg Schilling wrote:
> Vincent Lefevre  wrote:
> > Only bash, ksh93 and zsh document what happens concerning SIGCHLD traps.
> 
> Do you believe every shell should document SIGCHLD?
> Wouldn't it be sufficient if SIGCHLD is handled the same way as
> other signals?

Yes, this would be better.

> Well, /bin/sleep 0.1 is definitely not portable, I used /bin/sleep 1
> instead...

I mentioned the portability issue. You could replace it with
a different command that takes a fraction of time. I used 0.1
instead of 1 because I didn't want to wait for 30 seconds (this
was also an attempt to get different behaviors for the first
values).

> ksh93 delivers:
> 0
> 1
> 2
> 2
> 2
> 2
> 2
> ^C

Are you sure? Is there any reason why I don't get the same behavior
with ksh93?

> bash delivers:
> 0 
> 0 
> 0 
> 0 
> ^C 
> 
> zsh delivers:
> 0
> 7
> 30
> 30
> ^C
> 
> which looks similar to what ksh93 does.

Not with the above result you got.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-04-25 Thread Vincent Lefevre
On 2017-04-25 23:49:56 +0200, Jilles Tjoelker wrote:
> On Tue, Apr 25, 2017 at 03:21:24PM +0200, Vincent Lefevre wrote:
> > I wonder how the following script is supposed to behave.
> 
> > The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says:
> > "[...] a signal specified using a symbolic name, without the SIG prefix,
> > as listed in the tables of signal names in the  header defined
> > in XBD Headers"; there, SIGCHLD is listed as "Child process terminated,
> > stopped, [XSI] or continued". From this spec, I would assume that the
> > trap would be executed for any child process that terminates, stops, or
> > continues. But this is not what I observe.
> 
> I would not assume that. Since trap actions are not executed while
> waiting for a foreground process to exit, it is likely that multiple
> instances of SIGCHLD will be coalesced into a single trap action
> execution.

IMHO, this would be a bug. A shell should be able to know when all
its children have terminated. IMHO, all the pending traps should
be executed before the next command.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: SIGCHLD trap in a shell

2017-04-25 Thread Robert Elz
Date:Tue, 25 Apr 2017 15:21:24 +0200
From:Vincent Lefevre 
Message-ID:  <20170425132124.ga7...@cventin.lip.ens-lyon.fr>

I see Jillles has said much the same thing while I was preparing
this, but ...

  | I wonder how the following script is supposed to behave.

I wonder more if it has any expected behaviour.

  | I would assume that the
  | trap would be executed for any child process that terminates, stops, or
  | continues. But this is not what I observe.

I suspect here that your observations are (partly) incorrect.

  | 
  | #!/bin/sh
  | 
  | n=${1:-30}
  | n=$((n+0))
  | 
  | c=0
  | trap 'c=$((c+1))' CHLD
  | 
  | for i in `seq $n`; do /bin/sleep 0.1 & done
  | 
  | while true
  | do
  |   echo $c
  |   /bin/sleep 0.1
  | done
  | 
  | 
  | I call this script with:
  | 
  |
  | 
  | Under Debian unstable:

  | * With ash, dash, mksh and yash, I get:

With the NetBSD sh (which is an ash derivative) that is what I see too.

  | So, I get +1 only for commands that are not executed in background
  | (asynchronously).

No, that does not fit with your observations.  If that were true,m the first
output value would be 0, as the exct is done before the first foreground
sleep.

What is happening here is that all the background processes are created
at about the same time, all run for very little time, and all will terminate
at essentially the same time.  There's nothing that requires signals to be
queued anywhere (though they may be).

What I ovserve is that all the background sleep processes have finished
before the shell gets to the while true loop, and exactly one SIGCHLD trap
gets executed by the shell (setting c to 1) and then after that, it
all goes as you observe.

Of course, all this is horribly racy, and other outputs might also occur,

  | * With bash and posh, I get:

  | i.e. no trap executions at all.

That is also not unreasonable - systems are permitted to rescind SIGCHLD
if a child process is waited upon - and it is entirely reasonable to block
SIGCHLD (and perhaps other signals) while in the wait handler, so if no
children die at a time that the shell happens to have SIGCHLD unblocked
(which might not be a very long interval) it is possile for no CHLD signals
will ever be delivered.

kre





Re: SIGCHLD trap in a shell

2017-04-25 Thread Jilles Tjoelker
On Tue, Apr 25, 2017 at 03:21:24PM +0200, Vincent Lefevre wrote:
> I wonder how the following script is supposed to behave.

> The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says:
> "[...] a signal specified using a symbolic name, without the SIG prefix,
> as listed in the tables of signal names in the  header defined
> in XBD Headers"; there, SIGCHLD is listed as "Child process terminated,
> stopped, [XSI] or continued". From this spec, I would assume that the
> trap would be executed for any child process that terminates, stops, or
> continues. But this is not what I observe.

I would not assume that. Since trap actions are not executed while
waiting for a foreground process to exit, it is likely that multiple
instances of SIGCHLD will be coalesced into a single trap action
execution.

Also, SIGCHLD instances may be lost if waitpid() or similar calls
implicitly accept them. This is most likely if the shell calls waitpid()
with SIGCHLD masked but might also happen in a race otherwise.

> Only bash, ksh93 and zsh document what happens concerning SIGCHLD traps.

> Note: For practical reasons, I assume a sleep implementation with
> a floating-point number; this is the case with /bin/sleep under
> Debian (coreutils). It could be any external command with a similar
> behavior.

> 
> #!/bin/sh
> 
> n=${1:-30}
> n=$((n+0))
> 
> c=0
> trap 'c=$((c+1))' CHLD
> 
> for i in `seq $n`; do /bin/sleep 0.1 & done
> 
> while true
> do
>   echo $c
>   /bin/sleep 0.1
> done
> 

> I call this script with:

>

> Under Debian unstable:

> * With ash, dash, mksh and yash, I get:

> 1
> 2
> 3
> 4
> 5
> 6
> [...]

> and each time, $c is increased by 1.

> The +1 comes from the "/bin/sleep 0.1" of the "while" loop ("true"
> and "echo" being built-ins). If I replace them by external commands
> (/bin/true and /bin/echo), I get +3 each time.

> So, I get +1 only for commands that are not executed in background
> (asynchronously).

You can get the SIGCHLD trap action executed for background jobs by
doing slow things that do not fork, such as invoking the read utility.

FreeBSD sh behaves like this as well, with the addition of a check that
prevents nested SIGCHLD traps.

> * With bash and posh, I get:

> 0
> 0
> 0
> 0
> 0
> 0
> [...]

> i.e. no trap executions at all.

> If I add "set -m", then bash behaves like ash, etc., except that it
> no longer reacts to Ctrl-C (the Ctrl-C only interrupts the sleep).
> Anyway, "set -m" is not supposed to be used in shell scripts (see
> rationale for the "set" built-in).

"set -m" can be used usefully in scripts to put jobs into their own
process groups, like
  set -m; something & set +m

This example turns -m mode off immediately, since handling suspension of
foreground jobs is usually undesirable in a script.

Whether this works well depends on the shell implementation.

In any case it seems strange to tie SIGCHLD behaviour to "set -m".

> * With ksh93 and zsh, I get:

> 0
> 30
> 30
> 30
> 30
> 30
> [...]

> (or with a 29 just after the 0 -- this is just a timing reason),
> i.e. a trap execution only for asynchronous lists.

> This corresponds to the behavior of ksh88 as mentioned in the
> rationale for the "set" built-in. Is this the original intent?
> In any case, I think that this is the most useful behavior.

That seems more useful, but there is no text in POSIX that says to
implement it that way.

-- 
Jilles Tjoelker



Re: SIGCHLD trap in a shell

2017-04-25 Thread Joerg Schilling
Joerg Schilling  wrote:

> From my interpretation, only:
>
>   dash, bosh (the POSIXyfied Bourne Shell), mksh and yash
>
> and probably zsh
>
> work as expected.

BTW: I should have mentioned that this test cannot be done with the original 
Bourne Shell, as there, the script would need to contain:

trap 'c=`expr $c + 1`' CHLD

and this would cause a SIGCHLD storm as a result of the end of the "expr" 
process.

Depsite that fact, the original Bourne Shell could also be seen as compliant.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'



Re: SIGCHLD trap in a shell

2017-04-25 Thread Joerg Schilling
Vincent Lefevre <vincent-o...@vinc17.net> wrote:

> I wonder how the following script is supposed to behave.
>
> The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says:
> "[...] a signal specified using a symbolic name, without the SIG prefix,
> as listed in the tables of signal names in the  header defined
> in XBD Headers"; there, SIGCHLD is listed as "Child process terminated,
> stopped, [XSI] or continued". From this spec, I would assume that the
> trap would be executed for any child process that terminates, stops, or
> continues. But this is not what I observe.
>
> Only bash, ksh93 and zsh document what happens concerning SIGCHLD traps.

Do you believe every shell should document SIGCHLD?
Wouldn't it be sufficient if SIGCHLD is handled the same way as other signals?


> Note: For practical reasons, I assume a sleep implementation with
> a floating-point number; this is the case with /bin/sleep under
> Debian (coreutils). It could be any external command with a similar
> behavior.
>
> 
> #!/bin/sh
>
> n=${1:-30}
> n=$((n+0))
>
> c=0
> trap 'c=$((c+1))' CHLD
>
> for i in `seq $n`; do /bin/sleep 0.1 & done
>
> while true
> do
>   echo $c
>   /bin/sleep 0.1
> done
> 
>
> I call this script with:
>
>
>
> Under Debian unstable:
>
> * With ash, dash, mksh and yash, I get:
>
> 1
> 2
> 3
> 4
> 5
> 6
> [...]
>
> and each time, $c is increased by 1.

Well, /bin/sleep 0.1 is definitely not portable, I used /bin/sleep 1
instead...

I get this behavor with:

dash, bosh (the POSIXyfied Bourne Shell), mksh and yash.


zsh delivers:

0
9
30
30
30
30
^C

ksh88 delivers:
0
0
0
0
^C

ksh93 delivers:
0
1
2
2
2
2
2
^C

bash delivers:
0 
0 
0 
0 
^C 

zsh delivers:
0
7
30
30
^C

which looks similar to what ksh93 does.

> * With bash and posh, I get:
>
> 0
> 0
> [...]
>
> i.e. no trap executions at all.
>
> If I add "set -m", then bash behaves like ash, etc., except that it

bash -m script does not work for me...


>From my interpretation, only:

dash, bosh (the POSIXyfied Bourne Shell), mksh and yash

and probably zsh

work as expected.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'



SIGCHLD trap in a shell

2017-04-25 Thread Vincent Lefevre
I wonder how the following script is supposed to behave.

The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says:
"[...] a signal specified using a symbolic name, without the SIG prefix,
as listed in the tables of signal names in the  header defined
in XBD Headers"; there, SIGCHLD is listed as "Child process terminated,
stopped, [XSI] or continued". From this spec, I would assume that the
trap would be executed for any child process that terminates, stops, or
continues. But this is not what I observe.

Only bash, ksh93 and zsh document what happens concerning SIGCHLD traps.

Note: For practical reasons, I assume a sleep implementation with
a floating-point number; this is the case with /bin/sleep under
Debian (coreutils). It could be any external command with a similar
behavior.


#!/bin/sh

n=${1:-30}
n=$((n+0))

c=0
trap 'c=$((c+1))' CHLD

for i in `seq $n`; do /bin/sleep 0.1 & done

while true
do
  echo $c
  /bin/sleep 0.1
done


I call this script with:

   

Under Debian unstable:

* With ash, dash, mksh and yash, I get:

1
2
3
4
5
6
[...]

and each time, $c is increased by 1.

The +1 comes from the "/bin/sleep 0.1" of the "while" loop ("true"
and "echo" being built-ins). If I replace them by external commands
(/bin/true and /bin/echo), I get +3 each time.

So, I get +1 only for commands that are not executed in background
(asynchronously).

* With bash and posh, I get:

0
0
0
0
0
0
[...]

i.e. no trap executions at all.

If I add "set -m", then bash behaves like ash, etc., except that it
no longer reacts to Ctrl-C (the Ctrl-C only interrupts the sleep).
Anyway, "set -m" is not supposed to be used in shell scripts (see
rationale for the "set" built-in).

* With ksh93 and zsh, I get:

0
30
30
30
30
30
[...]

(or with a 29 just after the 0 -- this is just a timing reason),
i.e. a trap execution only for asynchronous lists.

This corresponds to the behavior of ksh88 as mentioned in the
rationale for the "set" built-in. Is this the original intent?
In any case, I think that this is the most useful behavior.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)