executing a script for a certain amount of time

I am writing a script that takes two parameters: the name of another script and an integer that represents a number of seconds. The script must execute the second script (first parameter) for the specified number of seconds (second parameter), suspend it for the same number of seconds, and continue this cycle until the specified script is finished.
For example:

pulse input.ksh 2

I have no idea how to run a script for a specified amount of time. I have looked at the "at" and "crontab" commands but these don't seem appropriate. Anybody know of a solution?

Thanks

why not run another script after n seconds which kills the first script.

try sleep
SYNOPSIS
sleep seconds

Pass the number of seconds to a variable immediately if you think the positional vars ($1, $2...) might change in your scripts.

like sleep "$AGAIN"

This has to be homework...

I agree that this looks like homework. Most scripts would run to conclusion rather than being abended before they finish.

I can't remember a time when I would run a script and then abend it to get my results. ????

I can't kill the script because it has finish executing. It is just being suspended for a certain amount of time.

Canbe homework, but i like to the trick too

Search the forums. I believe that we discussed a similiar problem with a process hanging and being killed after some given time delay.

I'm a little disappointed that the OP didn't bother to deny breaking our rules by posting a homework question.

But this turns out to be much harder than it first appears. I had a hard time doing this right and I must suspect that the OP's instructor underestimated the problem. So I am going to bend our rules a bit and offer a few hints on how to approach this.

If the subsidiary script is a script that never invokes another process, never forks and simply uses shell built-ins, this would be a very trivial problem. But if the subsidiary script invokes other processes, we really need to stop and restart all those processes in one fell swope. This implies working with process groups instead of processes. And ksh, the shell I used, has very limited support for process groups. In fact, I believe that I am relying on undocumented behavior of ksh. But I have tested this under HP-UX and it is working.

To get the master script to even employ process groups I had to do:
set -o monitor
early in the master script. Turning the monitor option on and off is really intended for interactive shells. I seemed to get away with it in a script. Most of the job control stuff did not work very well in non-interactive mode. I was hoping that I just just use the job control commands in a script, but there were too many problems with them. But with monitor mode set, the shell put background jobs in a seperate process group and it set the process group id to the process id returned in the $! parameter. I expected this behavior, but I can't find it documented on the ksh man page.

But now I had both the pid and process group id of the background process. The kill command can take a negative number as the second argument. If it is not -1, it is taken as a process group id and the signal is sent to all members of the process group.

The signal SIGSTOP will cause a process to suspend. And the signal SIGCONT will cause a stopped process to resume.

When the subsidiary process finishes, the process group will persist until all members of the process group have exited. At that point, a kill command target to the now defunct process group will fail. A script can check the return code fro the kill command to detect when this happens.

This should be enough clues to complete the homework assignment. Have fun... I did!

Another way to do it I found out, is to use some arguments of the kill command: kill -STOP and kill -CONT. This works great when used with a loop.