Cocoa mail archive
Re: Finding out executable location from a c program
FROM : Alastair Houghton
DATE : Tue Nov 27 13:11:28 2007
On 23 Nov 2007, at 20:52, Antti Karanta wrote:
> On Tue, 20 Nov 2007 14:36:53 +0200, Alastair Houghton <<email_removed>
> > wrote:
>
>> It's perhaps worth saying though that using the path of your tool
>> is generally an evil thing to do.
>
> Why is it evil?
Because you can't guarantee that you can get the path, in general.
You have to use system-specific hacks to obtain it, and on some
systems there's no way to reliably find the path of the running
program. Even on systems that do let you obtain such a path, you may
find that the path is that of a symlink (which may or may not be an
issue, depending on what you do with it).
Furthermore, even if you do find the path somehow, a malicious (or
just misguided) user could move things around between the time you
obtain the path and the time your code is actually running. This has
the potential to create security holes in certain circumstances (e.g.
by causing you to load corrupted files and/or execute processes or
scripts with the privileges of the user running your program).
> I'm not in control of how groovy distribution is laid out, but even
> if I was I can not see what would be the benefit of separating the
> launcher executable and the rest of the distribution (into "normal
> UNIX places") versus keeping the distribution file layout the same
> on all platforms.
For the type of application you're talking about, hard-coded paths
seem the most sensible choice, possibly allowing GROOVY_HOME to
override them if it's set. You can easily find the paths to use when
your users build your program (it looks like the type that's built
from source, right?)
And if you want to package-up pre-built versions of your launcher with
Groovy itself, you can do that too, using the various system-specific
packaging tools (e.g. PackageMaker on OS X). Certainly on OS X, many
users would prefer to be able to double-click a "Groovy.pkg" file
anyway. The same is true, I think, for other systems.
If you do that, you can delete all the grotty code to find the
executable path on all the systems you currently support, *and* the
program will be more likely to run without modification on other
systems too.
Kind regards,
Alastair.
--
http://alastairs-place.net
DATE : Tue Nov 27 13:11:28 2007
On 23 Nov 2007, at 20:52, Antti Karanta wrote:
> On Tue, 20 Nov 2007 14:36:53 +0200, Alastair Houghton <<email_removed>
> > wrote:
>
>> It's perhaps worth saying though that using the path of your tool
>> is generally an evil thing to do.
>
> Why is it evil?
Because you can't guarantee that you can get the path, in general.
You have to use system-specific hacks to obtain it, and on some
systems there's no way to reliably find the path of the running
program. Even on systems that do let you obtain such a path, you may
find that the path is that of a symlink (which may or may not be an
issue, depending on what you do with it).
Furthermore, even if you do find the path somehow, a malicious (or
just misguided) user could move things around between the time you
obtain the path and the time your code is actually running. This has
the potential to create security holes in certain circumstances (e.g.
by causing you to load corrupted files and/or execute processes or
scripts with the privileges of the user running your program).
> I'm not in control of how groovy distribution is laid out, but even
> if I was I can not see what would be the benefit of separating the
> launcher executable and the rest of the distribution (into "normal
> UNIX places") versus keeping the distribution file layout the same
> on all platforms.
For the type of application you're talking about, hard-coded paths
seem the most sensible choice, possibly allowing GROOVY_HOME to
override them if it's set. You can easily find the paths to use when
your users build your program (it looks like the type that's built
from source, right?)
And if you want to package-up pre-built versions of your launcher with
Groovy itself, you can do that too, using the various system-specific
packaging tools (e.g. PackageMaker on OS X). Certainly on OS X, many
users would prefer to be able to double-click a "Groovy.pkg" file
anyway. The same is true, I think, for other systems.
If you do that, you can delete all the grotty code to find the
executable path on all the systems you currently support, *and* the
program will be more likely to run without modification on other
systems too.
Kind regards,
Alastair.
--
http://alastairs-place.net
