[launchd-dev] Can a launchd job get any access to its invoking plist?

[Norman Gray]

Damien (and Jerry), hello.

On 2013 Dec 4, at 20:10, Damien Sorresso <dsorresso at apple.com> wrote:

> On 4 Dec, 2013, at 12:05, Jerry Krinock <jerry at ieee.org> wrote:
>> On 2013 Dec 04, at 11:22, Damien Sorresso <dsorresso at apple.com> wrote:
>> 
>>> Why not just set a relevant environment variable or pass an argument that's different in each plist?
>> 
>> I’ve done that, Damien, but like Norman I have wondered why the job’s parameters are not more readily available.  
> 
> Because the launchd.plist is not a preferences container. It's not meant to be a state store.

Sure, and I'm storing the actual state in preferences, using NSUserDefaults.  All I really want to know is "Have I been invoked from A.plist or B.plist?"

I've tried setting an environment variable, and passing an --ident option to the program.  That does work, but in each case it involves copying the Label from one part of the plist to another: that looks ugly, is redundant, and requires extra documentation ("Copy the Label to the --ident option; don't ask why...").

I've even resorted to concatenating various arguments and options, and using that as the 'identifier', but that ends up looking needlessly obscure.  In fact, if I could read the Label and (in my case) the WatchPaths from the calling environment, then several of my program options would disappear.

So I'm not thinking of the job parameters as _state_, quite, but as part of the program launch environment.  Rather than (argc, argv, environ), it's effectively (argc, argv, environ, plist).  That's not traditional unix, of course, but then launchd isn't traditional unix either.

> If you need to modify your program's behavior, you should specify different arguments or a different environment in the plist. That is what those entries are for.

Indeed, but in this case the information being communicated is information about the plist itself, which seems... clumsy.  That in turn makes me suspect I'm doing something the Hard Way.

@Graham: thanks.  launch_data_dict_lookup looks like it would do the job, and demonstrates that Apple feel that the information is legitimately available in at least some circumstances.  But the fact that it's not documented _anywhere_ I can find (other than being implicitly documented as part of Apple example code), makes me nervous of using it.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK