After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 615903 - [PATCH] add a way to get the path to the executable
[PATCH] add a way to get the path to the executable
Product: glib
Classification: Platform
Component: general
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
Depends on:
Blocks: 172268
Reported: 2010-04-15 22:31 UTC by Paolo Bonzini
Modified: 2018-05-24 12:14 UTC
See Also:
GNOME target: ---
GNOME version: ---

second patch (8.81 KB, patch)
2010-04-15 22:32 UTC, Paolo Bonzini
none Details | Review
first patch (1.97 KB, patch)
2010-04-15 22:33 UTC, Paolo Bonzini
none Details | Review
update to second patch (8.97 KB, patch)
2011-01-26 19:51 UTC, Paolo Bonzini
none Details | Review

Description Paolo Bonzini 2010-04-15 22:31:40 UTC
glib provides no way to retrieve the path to the executable.  This is useful in order to implement fully relocatable packages, for example.

The first patch here fixes some imperfections in the documentation.

The second adds a new interface to be used instead (or in addition to) g_set_prgname.  This interface receives the whole argv[0] so that it can be used to scan the path.  The default prgname becomes the basename of the argv0 value.

GOption is tweaked to call the new interface instead of g_set_prgname.

The Mac OS X part is untested beyond compilation.  FreeBSD could also be added (using sysctl).

Automated testing is difficult, I used this program

#include <glib.h>

int main(int argc, char **argv)
  g_set_argv0 (argv[0]);
  printf ("%s\n", g_get_executable_path ());
  printf ("%s\n", g_get_prgname ());

with various combinations of paths and argv[0] values.
Comment 1 Paolo Bonzini 2010-04-15 22:32:30 UTC
Created attachment 158847 [details] [review]
second patch
Comment 2 Paolo Bonzini 2010-04-15 22:33:08 UTC
Created attachment 158848 [details] [review]
first patch
Comment 3 Christian Dywan 2010-04-16 00:10:39 UTC
I dislike that g_get_argv0 returns a default value on Windows but has to be manually set on all other platforms. This is an invitation for surprises in portable code. And it isn't even explained in the documentation comment. The same concern applies to g_get_executable_path, except that it at least documents that flaw.

I would suggest a function g_set_executable_path should unambiguously set the path, as given by the caller. And gtk_init may well do that by default. Otherwise writing something like "gchar* path = g_path_get_basename (argv[0]); g_set_executable_path (path); g_free (path);" is simple enough for Glib programs to do.
Comment 4 Christian Persch 2010-04-16 12:20:13 UTC
See also bug 172268.
Comment 5 Paolo Bonzini 2010-04-19 16:45:51 UTC
Christian, I agree with your assessment.  However, I had two choices:

1) do as I did;

2) keep this quirk in g_get_prgname (for bugwards compatibility) and not in g_get_argv0.

However, 2 complicated the code unnecessarily, so I went with this patch.  Thanks for the review!

For the record, I'm indeed using this function to implement relocatability.
Comment 6 Behdad Esfahbod 2010-05-29 17:31:56 UTC
Don't like argv0 in the function name.
Comment 7 Paolo Bonzini 2010-05-31 10:26:40 UTC
Any suggestions?  g_compute_executable_path?
Comment 8 Behdad Esfahbod 2010-05-31 20:16:25 UTC
Comment 9 Paolo Bonzini 2010-06-01 15:45:30 UTC
1) The new functionality is in g_get_executable_path, this is the main entry point added by the patch.  Most programs will never see g_get_argv0/g_set_argv0.  

2) g_get_argv0 is just retrieving what was set by g_set_argv0.  I'll change the patch to make g_get_argv0 unnecessary.

3) g_set_argv0's name is not any better.  That's what I was suggesting to rename to g_compute_executable_path.  The reason why it exists is exactly because Christian's suggested code

  gchar* path = g_path_get_basename (argv[0]);
  g_set_executable_path (path); g_free (path);

is not enough, you need the entire argv[0] to find the executable in a robust manner.  I'll rename this to g_find_executable_path.  This is imprecise because actually the search is delayed to the first call to g_get_executable_path, but that's an implementation detail.
Comment 10 Maia Everett 2010-09-10 06:58:09 UTC
I would like to have this functionality, as it eases making an application that can read its data files from different locations depending on where it's launched from.

Qt has it implemented in QCoreApplication::applicationFilePath(), which can be seen here:
Comment 11 Maia Everett 2010-09-10 07:10:33 UTC
Looking at the patch, what's the point of having g_get_arvg0/g_set_argv0 in the public API? Can they not be made static?
Comment 12 Christian Dywan 2010-09-10 14:03:37 UTC
(In reply to comment #11)
> Looking at the patch, what's the point of having g_get_arvg0/g_set_argv0 in the
> public API? Can they not be made static?

Unlike Qt, GLib has no initialization function, so you need a way to pass argv0.
Comment 13 Paolo Bonzini 2011-01-20 17:26:24 UTC
Comment 14 Paolo Bonzini 2011-01-20 17:29:47 UTC
About the ping, is the patch okay with:

1) g_get_argv0 made internal to glib

2) g_set_argv0 renamed to g_find_executable_path


If so, I can post an updated one.  However, I'm totally lost as to what I should do to get the patch into glib.
Comment 15 Paolo Bonzini 2011-01-26 19:51:18 UTC
Created attachment 179399 [details] [review]
update to second patch
Comment 16 GNOME Infrastructure Team 2018-05-24 12:14:13 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: