FROM : Carsten
DATE : Sun Mar 23 09:43:41 2008
On 23/03/2008, Marcus <<email_removed>> wrote:
> I agree. I would recommend /usr/local/bin if you're only targeting
> Leopard. Tiger and previous versions of Mac OS X does not come with /
> usr/local and doesn't have it in the user's path.
A-ha, I didn't know that! Hmm, that makes it a bit harder. Dumping
stuff into /usr/bin is not nice, but perhaps it is the best way, in
case /usr/local doesn't exist. On the other hand, by the time I have
finished developing my app, Leopard will probably be ubiquitous :)
> > I am not sure what the advantage of using an NSBundle over a script
> > is. The location (/usr/bin in your suggestion) is important here, as
> > long as it is in the path.
>
>
> My idea was that you could have the graphical application and any
> command line tools inside your application bundle. Many applications
> does that and puts a symlink when it is being used for the first time
> in /usr/bin that links to the tool inside the application bundle. The
> problem with that is that the symlink will break if the application
> bundle is moved or renamed.
Ah, okay, I see now. My script will just launch the application
executable with a specific commandline that forces it into batch mode,
so the difference in functionality or convenience between a symlink to
a tool and a generated one-liner script (plus some error handling for
a broken link) is probably too small to bother about the development
of the tool, I think.
Thanks again,
Carsten
DATE : Sun Mar 23 09:43:41 2008
On 23/03/2008, Marcus <<email_removed>> wrote:
> I agree. I would recommend /usr/local/bin if you're only targeting
> Leopard. Tiger and previous versions of Mac OS X does not come with /
> usr/local and doesn't have it in the user's path.
A-ha, I didn't know that! Hmm, that makes it a bit harder. Dumping
stuff into /usr/bin is not nice, but perhaps it is the best way, in
case /usr/local doesn't exist. On the other hand, by the time I have
finished developing my app, Leopard will probably be ubiquitous :)
> > I am not sure what the advantage of using an NSBundle over a script
> > is. The location (/usr/bin in your suggestion) is important here, as
> > long as it is in the path.
>
>
> My idea was that you could have the graphical application and any
> command line tools inside your application bundle. Many applications
> does that and puts a symlink when it is being used for the first time
> in /usr/bin that links to the tool inside the application bundle. The
> problem with that is that the symlink will break if the application
> bundle is moved or renamed.
Ah, okay, I see now. My script will just launch the application
executable with a specific commandline that forces it into batch mode,
so the difference in functionality or convenience between a symlink to
a tool and a generated one-liner script (plus some error handling for
a broken link) is probably too small to bother about the development
of the tool, I think.
Thanks again,
Carsten
| Related mails | Author | Date |
|---|---|---|
| Carsten | Mar 22, 23:26 | |
| Tom Harrington | Mar 22, 23:36 | |
| Carsten | Mar 23, 00:01 | |
| Marcus | Mar 23, 06:46 | |
| Carsten | Mar 23, 09:10 | |
| Marcus | Mar 23, 09:31 | |
| Carsten | Mar 23, 09:43 | |
| Brian Stern | Mar 23, 18:35 | |
| Carsten | Mar 23, 22:08 | |
| Scott Ribe | Mar 23, 22:16 | |
| Sherm Pendley | Mar 23, 22:35 | |
| Carsten | Mar 23, 22:43 |






Cocoa mail archive

