Killing the correct process

[Maarten Litmaath]

In article <1381 at root44.co.uk>,
	gwc at root.co.uk (Geoff Clare) writes:
)...
)This isn't very useful - how do you predict how long the command will
)need to clean up?  Two seconds is plenty for most commands.

For *most* commands (according to you, anyway) - why not let the user
specify the delay?  It's no trouble at all and leads to higher generality.
You shouldn't say too quickly: "The user doesn't need it."
That's the approach which leads to things like:

	$ set a b c d e f g h i j
	$ echo $10	# echo parameter 10
	a0		# oops!

"The user doesn't need more than 9 arguments."

)...
)So now you can tell when something went wrong, but you still aren't
)getting the full picture.  If the command is terminated by a signal
)your script will instead exit with a non-zero exit code (usually
)128 + signal number).

You're right again!  I've posted another script to alt.sources, which does
things your way (at last! :-), but having a few extras too.

)Another big advantage in having the parent execute the command is that
)it is then a normal foreground process, so you can use the INTR and QUIT
)keys in the normal way.  If the user interrupts your script, he gets
)a prompt back and may think he has killed the command, whereas in fact
)it's still running in the background.

Only the sleep (and its wait()ing parent) keep running, *just* like in
your approach!

)...
)The script was designed for casual use from a terminal.

Yours, not mine.

)If I ever
)wanted to put it to more serious use, I could get rid of the leftover
)sleep by adding another background process to monitor the other two.
)Or better still, I would use a C program.

One thing that's clear from our discussion: sh isn't powerful enough! :-(

)>Another plus of timeout 5.0: the signal is now a parameter too.
)
)Another unnecessary frill.  SIGTERM is the right signal to use - that's
)why it's the default for the "kill" command.

Again I don't agree; first there's the generality, then there's the fact
that SIGHUP is used to signal exceptions too, and lastly both SIGALRM and
SIGXCPU seem normal to send on a *timeout*.
--
  "Belfast: a sentimental journey to the Dark Ages - Crusades & Witchburning
  - Europe's Lebanon - Book Now!" | maart at cs.vu.nl,  uunet!mcsun!botter!maart