Greg Wooledge wrote: > Bob Proulx wrote: > > P.S. In the old days mixing sleep(3) and SIGALRM was frowned upon. ... > > But this is bash, so you're using sleep(1) not sleep(3).
Actually on GNU systems it is the coreutils sleep(1) and not related to bash at all. :-) > In other words, the "sleep 5" is an external process, and its > handling (or non-handling) of SIGALRM should in no way affect the > trap set by bash. Agreed that bash's trap handling shouldn't affect sleep. But because sleep might be using SIGALRM itself it isn't a good idea to be sending SIGALRM to a sleeping process of ksh, coreutils, perl, ruby, internal, external or otherwise. But any other signal is okay. SIGTERM seems most appropriate for this task anyway. Probably a good idea to avoid throwing SIGALRM at any sleeping process. But I agree with your point that bash itself wasn't sleeping and so that didn't matter there. But it would be very easy for a programmer to change the target of the SIGALRM throw from bash to sleep and then fall into the possible trap of SIGALRM and sleep interaction depending upon environment. My point was why risk it when SIGTERM feels like the better signal to use anyway. I should have changed the example I re-posted to use SIGTERM instead. Bob
