[launchd-dev] Programmatic interface to launchctl and some other questions, OS X 10.5

[eveningnick eveningnick]

Thank you for the answer!

> If you need to manipulate the launchd state, you should use Service Management (if it's available and does what you want) or simply fork/exec launchctl.  And yes, it is both sad and a chore )-:

> The approach I usually use here (for example, this is what BAS shows) is to have my launchd job provide a service, and then try to connect to that service.  If the connection works, the job must be installed properly.  If the connection fails, some corrective action is necessary.

Could you tell a little more about what kind of services do you
provide usually and how do you respond to them? Is it something like
AppleEvents? Or some kind of user-signals?


>Well, yes.  But launchd is *normally* used in this way, to launch gui-less tools.  The path to your tool is the first element in the ProgramArguments array.  If you wanted to launch an *app* with launchd, you'd need to use /usr/bin/open.

But how should it be done? Do i need to save a plist file to
/users/myuser/library/launchagents? or can i have it dynamically? As i
understand for now, to correctly launch a GUI-less tool (for example,
ls), i need:
1) generate plist file (using NSDictionary, for example -  and
correctly fill ProgramArguments field there)
2) save that plist file somewhere on disc (for example, some kind of tmp folder)
3) call fork/exec with params launchctl load "a/path/to/my/saved/plist/folder"
4) call fork/exec with params launchctl start "my.justloaded.nongui.app.label"
5) if i want to terminate that application, i have to fork/exec
launchctl unload "my.justloaded.nongui.app.label"
6) then i have to delete that temporary plist file (at what moment of
program execution?)

Is it the only right way? Sounds like a bit of overhead.. Could you
comment these steps?
Thanks again!