Task Managements

On Mon, 17 Jul 2006 00:10:43 -0500, Ron Johnson wrote:

> "background" and "in sequence" are a bit (no, a *lot*) contradictory.

yeah, so true.

hi, thanks everyone who replied.

> What you probably want is a *sequence* and put *it* in the background.
> This, maybe:
>
>   (task-a && sleep 2 && task-b) &

or as Cameron suggested

{ task-a ; task-b ; } &

to avoid needlessly forking.

This is the common theme for all the answers so far. But the problem is that my background tasks are real background tasks, eg. emacs and tk scripts, that they'd not finish and return.

So I guess that I have to rely on longer sleeping then?

T

> So I guess that I have to rely on longer sleeping then?

Some years ago, I had to solve a problem like this, and my solution was "done-files." I was writing a system programs that relied on each others input. Platform constraints that I can't remember obliged me to start all three programs asynchronously, so I made each program write a file name of <program>-done.$$$ upon finishing.

For example, if the programs were named stage1, stage2 and stage3; stage1
would create a zero-byte file named stage1-done.$$$, and stage2 would
write stage2-done.$$$ when it was finished. Stage3 didn't need to write a
"done-file".

Stage2 would wait for stage1-done.$$$ to appear before doing anything, and
stage3 would wait for stage2-done.$$$ before doing anything. So I was able
to get three asynchronously run programs to act synchronously.

Mumia W.

>> This is the common theme for all the answers so far. But the problem is
>> that my background tasks are real background tasks, eg. emacs and tk
>> scripts, that they'd not finish and return.
>
> does this mean you need to start task-a, wait a little and then start
> task b to run concurrently with task-a?

Exactly.

One example is my TK script. I guess I can use Mumia's done-file approach.

The other is actually plain emacs. I started my 1st emacs session with -geometry parameter to position it at a exact location on my x-win, then the 2nd one is grouped to it by my fluxbox — the nice feature of fluxbox that allows applications that you choose to share the very same place on X.

It sound a bit confusion but the bottom line is, yes, I need to do exactly what you've described.

T

>> does this mean you need to start task-a, wait a little and then start
>> task b to run concurrently with task-a?
>
> Exactly. [...]
>
> It sound a bit confusion but the bottom line is, yes, I need to do
> exactly what you've described.

Then how about:

{task-a &} && sleep 5 && {task-b &}

Ron Johnson, Jr.