Re: SIGCHLD trap in a shell

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

Re: SIGCHLD trap in a shell

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;

Re: SIGCHLD trap in a shell

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

Re: SIGCHLD trap in a shell

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

Re: SIGCHLD trap in a shell

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.

Re: SIGCHLD trap in a shell

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

Re: SIGCHLD trap in a shell

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

Re: SIGCHLD trap in a shell

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

Re: SIGCHLD trap in a shell

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

Re: SIGCHLD trap in a shell

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

Re: SIGCHLD trap in a shell

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.

Re: SIGCHLD trap in a shell

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 >

Re: SIGCHLD trap in a shell

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

POSIX 1003.1-2016 certification

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