On Sat, 2007-04-07 at 15:24 -0300, Rodrigo Barbosa wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, Apr 07, 2007 at 02:08:35PM -0400, William L. Maltby wrote:
> > On Sat, 2007-04-07 at 14:03 -0400, William L. Maltby wrote:
> > > On Sat, 2007-04-07 at 14:20 -0300, Rodrigo Barbosa wrote:
> > > <snip>
> >
> > > >
> > > > <snip>
> > Almost forgot - you might enjoy looking at the "trap" command in bash
> > (and other shells). Allows entry to arbitrary routines based on
> > asynchronous events, similar to signal handling in "C". Receiving
> > function has the choice of resetting the trap, issuing arbitrary actions
> > and signals, setting other traps, etc. Fun stuff.
>
> Yup, used it in the past.
>
> Actually, my idea for using (...)& is because of the trap. This way,
> you can trap SIG_ALARM as you would with sigaction, and use
> (...)& as you would alarm().
Since the (...)& and {...} are in-line, they have some minor reduced
usefulness as compared to trap. Because setting the trap, and processing
the trap when a signal is received, returns to the script position it
happened to be executing when the signal was received, you don't need to
have something like and alarm followed directly by the kill. You can set
the alarm, let the shell do wome other things and the signal will cause
entry to the "trap code" regardless of what else is going on. And then
execution can continue at the place the shell/process was interrupted.
BUT, it's use is not nearly as straightforward. And first time users
will have to work a little harder at understanding how to use it
effectively (or... at all) because there are no samples in the docs. But
they know how to Google I think. That'll fill in the missing pieces for
them.
> <snip sig stuff>
Well, end of thread? We might have overstayed our welcome on this
already.
I've enjoyed it.
--
Bill