This reminds me very much of a problem I've had with a helper
application executable in the main application's MacOS directory. In
Activity Monitor, the main application's name is given as the process
name of the helper application, rather than the helper application's
own name.
From what
Thanks, Michael. I just figured out what was going on, and you're
absolutely right.
My helper's name is alphabetically before the main executable.
LaunchServices was choosing it to be launched as my application, and
the exit code (I should have realized) was the helper not
understanding the argume
On Wed, Apr 22, 2009 at 7:28 PM, Sidney San Martín wrote:
> I just discovered a new behavior that might be helpful. I'm storing my
> helper in MacOS (so that it can be located with [NSBundle
> pathForAuxiliaryExecutable:]). The call to openFile: causes both my
> application and helper to be execut
On Wed, Apr 22, 2009 at 6:41 PM, Sidney San Martín wrote:
> I have read TN2083. Is there anything in particular that sticks out as
> bad practice or as the potential cause of my issue?
I was under the impression that you were attempting to do unattended updates.
--Kyle Sluder
___
I just discovered a new behavior that might be helpful. I'm storing my
helper in MacOS (so that it can be located with [NSBundle
pathForAuxiliaryExecutable:]). The call to openFile: causes both my
application and helper to be executed. My application exits (or so
launchd says, even if I put an NSLo
Note: I'm re-sending this to the list. Accidently replied only to the sender.
---
I have read TN2083. Is there anything in particular that sticks out as
bad practice or as the potential cause of my issue?
Note that the application in question is not a daemon and will always
be launched by a consol
You would be very well served to read TN2083, Daemons and Agents:
http://developer.apple.com/technotes/tn2005/tn2083.html . You seem to
be unaware of some of the pretty important architectural
considerations that will affect your implementation. Notably, some
things changed in Leopard that will h
I'm running into an issue that's above my skill level and could really
use some guidance. My application has an SUID-root update utility (I
know that's unusual, but it's an internal application that needs to be
able to update itself even when the logged-in user isn't privileged)
stored inside the a
