On 8/20/15 7:50 PM, Travis Paul wrote: > sleep (/bin/sleep) isn't built-in to /bin/sh, so my guess is that > /bin/sleep is catching signal. I think that the 2nd version works > because when you have a loop in sh and sleep for 1 second and there is > time for /bin/sh to catch the signal.
Hi, Travis. Thanks for your reply! For the second version, I think it works because sh "sees" the signal once the "sleep 1" returns. For the first version, I still don't understand why sh doesn't "see" the signal while waiting in the wait. That's the behavior that seems strange to me. As far as your guess that /bin/sleep is catching the signal, I don't understand that. When I run "/bin/sleep 3600" on its own in a terminal and send it SIGHUP, it exits immediately like this: === sleep terminal === $ /bin/sleep 3600 Hangup ====================== So, if, when running in test-program, it is catching the SIGHUP that was sent to test-program, why wouldn't it just exit like it does when I send the SIGHUP to it directly, and then test-program should exit since the wait should return? Furthermore, since the sleep is running in the background, I don't understand how a SIGHUP sent to test-program would somehow get caught by the sleep; that doesn't make sense to me. Thanks! Lewis
