Finding out executable location from a c program

[Antti Karanta]

> -----Original Message-----
> From: Alastair Houghton [mailto:alastair at alastairs-place.net]
> 
> On 23 Nov 2007, at 20:52, Antti Karanta wrote:
> 
> > On Tue, 20 Nov 2007 14:36:53 +0200, Alastair Houghton
> <alastair at alastairs-place.net
> > > 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, 

  System specific, yes, but "hack" is a pretty strong word here as (at
least on the four os:es I'm currently targeting) there is a well defined
and documented way to get the said path.


> Even on systems that do let you obtain such a path, you may
> find that the path is that of a symlink 

  Not a problem, I just call "realpath" function. 


> 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.  

  Doesn't this scenario equally apply to the situation where you place
the files you need in a "known location"?


> 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?)

  Most people would not build the main groovy distribution themselves.
ATM people who want to use the native launcher have to build that
themselves (except on windows). So the answer is yes(ish), at least for
now.


> 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.

  You are absolutely right.


> 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.

  Ok, I see your point - when in Rome, do as the Romans do. = ) 


  BTW, if I made a bundle, the code I have would be exactly the same (as
I'm using the bundle API to find the exec location). Why would finding
the necessary files by the executable location be any more justified in
that case? I.e. is the existence of this part of the bundle API a
mistake?



       -Antti-