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
