GNOME Bugzilla – Bug 615903
[PATCH] add a way to get the path to the executable
Last modified: 2018-05-24 12:14:13 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.
Created attachment 158847 [details] [review] second patch
Created attachment 158848 [details] [review] first patch
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.
See also bug 172268.
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.
Don't like argv0 in the function name.
Any suggestions? g_compute_executable_path?
g_get_exec_path?
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.
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: http://git.meyerhome.net/icefox/qt-snapshot/tree/qt/4.5/src/corelib/kernel/qcoreapplication.cpp
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?
(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.
ping?
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.
Created attachment 179399 [details] [review] update to second patch
-- 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: https://gitlab.gnome.org/GNOME/glib/issues/286.