Thank you. I am sorry, I should have tested how it behaves with ordinary applications before. I just realized that I was wrong about the source of the issue i am having. [NSTask launchTaskForPath] works perfectly on both systems, for both GUI (bundled .app) and command line applications - it works, because we are able to start an application from a Terminal (and terminal fork()/exec() 's the binary). So, [NSTask] works, unless we decide to call it from a spawned-by-launchd application (i.e, an agent). When I do this, an application appears to be spawned in a different boostrap context (or something like that). Due to some change in bootstrap spaces, an agent can spawn ordinary-user's processes without any side effects in Snow Leopard - Apple moved everything related to a user into one bootstrap space (in contrary to several pink rectangles that are shown in the Daemons & Agents technote). But not in Leopard.
The only option i have, i guess, is to ask Launch Services (or NSWorkspace) to launch my app, as suggested. 2011/6/11 Greg Guerin <[email protected]> > Nick wrote: > > This "per user" idea does not let me use any advertisement-based IPCs >> (like >> user domain sockets or bonjour ). I need some "per user only" IPC - so >> other >> >> user's instance of the process does not interfere with the current user's >> one. >> > > > A Unix domain socket can be placed anywhere in the file-system, AFAIK. So > put it in the user's home directory, probably best in a sub-dir like > ~/Library/Application Support/YourAppNameHere/. A location under user's > home dir also ensures that access permissions are applied when addressing > the socket. The name need not be advertised if both parties already know > its pathname. > > http://en.wikipedia.org/wiki/Unix_domain_socket > "UNIX domain sockets use the file system as address name space." > > Also, Bonjour service type names may incorporate unique identifiers. For > example, the user-name or user id, or a GUID known to both parties. (Obey > limits on service type name length, and consider vulnerability to spoofing > attacks.) > > -- GG_______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/eveningnick%40gmail.com > > This email sent to [email protected] > _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
