On Mon, Jul 17, 2006 at 04:09:32PM +0200, T wrote:
> On Mon, 17 Jul 2006 09:58:33 -0700, Andrew Sackville-West wrote:
>
> >> >> I find that in many cases I need my background tasks to be executed
> >> >> in sequence. Ie, I need background task-b to start right after
> >> >> background task-a has properly started.
[snippage ...]
> >>
> >> 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.
> >
> > 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.
>
so you want the emacs to be fully started so that fluxbox can grab the
next and group it properly, right? maybe you can wrap the second
instance in something that checks the status of the first one before
proceeding. maybe something as simple as checking its xprop's though
that's probably not the right tool, so that when it is assigned
properties by X, then you know that fluxbox knows where it is and can
proceed. this is out of my league, but maybe I've helpd clarify the
problem better.
A
Attachment:
signature.asc
Description: Digital signature