Re: Proposal: an addition to glib for getting the absolute path of the current binary.

[Mike Hearn <mike navi cx>]

On Tue, 13 Apr 2004 22:14:37 +1200, Laszlo Peter wrote:
> Hmm... it'd be great to find a platform independent
> solution -- something that would also work on, say, Solaris (;

Well, I have no clue whether Solaris has an equivalent of /proc, but if
not it might be good to have one.

> Since on most Unix flavours there's no way to find the path to the
> running binary, I think we should try something else. 

Ah, well this is the sticking point where we all start disagreeing, it
seems. I think hacks that rely on scanning $PATH, or trying random paths
or reading config files or whatever are just really bad, and that it's the
responsibility of the underlying OS to make this work.

You work at Sun, you must be able to file a bug report against the Solaris
kernel/rtld if there is no way to get the absolute location of a binary,
right? How are Solaris binaries supposed to do this currently: surely not
by having hundreds of environment variables and config files?

> I believe this proposal addresses all the issues in the original post,
> except when a non-root user wants to install something. Something like a
> dot-file in $HOME could help. It would only be used if (getuid () ==
> geteuid ()).

Well, it does, but this seems an awful hack. Having a config file tell the
program where it is isn't really portable to Windows either, to be frank.

> This is what much of the GNOME code currently does: You put
> -DFOODIR=\"$(foodir)\" in your Makefile and then you have something like
> 
> 	FOODIR "/relative/path/to/file"
> 
> in the C code. Instead, you could just use
> 
> 	g_find_file ("foodir", "/relative/path/to/file")

I think that's asking for incorrect paths, to be honest, but I don't know
how easy it is to get new features into Solaris. From the fact that you
haven't even raised the possibility, I'm guessing the answer is that it's
not easy :(

FYI, the current binreloc API (which is standalone) allows you to change:

        FOODIR "/relative/path/to/file"

with
        FOODIR( "/relative/path/to/file" )

and the returned string can be used until the next invocation of the macro
at which point it's freed. It makes memory management a bit simpler. This
is of course thread safe.

I'm not proposing that sort of API for glib, but I thought it might
provide a useful data point.

thanks -mike