On 4 Dec, 2013, at 12:58, Norman Gray <nor...@astro.gla.ac.uk> wrote:
> Damien (and Jerry), hello.
>
> On 2013 Dec 4, at 20:10, Damien Sorresso <dsorre...@apple.com> wrote:
>
>> On 4 Dec, 2013, at 12:05, Jerry Krinock <je...@ieee.org> wrote:
>>> On 2013 Dec 04, at 11:22, Damien Sorresso <dsorre...@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.
It seems like you're basing a ton of behaviors simply on the job's label. Why
do they have to be based on that? That said, I think it's reasonable to export
the job's label in an environment variable or something. But plist is not there
as part of the program's environment. It *defines* the program's environment.
Also, I can see how WatchPaths are clumsy in this case, but then again, the
entire mechanism of WatchPaths is clumsy. You're virtually guaranteed to miss
modifications a certain amount of the time, and you have no guarantee that the
write which triggered the modification event left the file in a consistent
state anyway.
>> 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,
Those interfaces are really only so that jobs can check in with launchd to
obtain listening sockets. They were way too general at the outset.
--
Damien Sorresso
dsorre...@apple.com
_______________________________________________
launchd-dev mailing list
launchd-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/launchd-dev
