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(),
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;
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
On 5/10/17 9:19 AM, Joerg Schilling wrote:
> 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
>
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
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 i
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 n
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 pr
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 c
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
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 t
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
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. Ea
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
> >
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
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
All
(Apologies for the off topic repost - we’d appreciate if you pass this along to
any open source projects that might be relevant - we’re particularly keen to
reach out to the BSD as well as Linux communities - even if you are not
interested in certification - it can be useful to assess compl
17 matches
Mail list logo