topic Re: C/C++: how to retrieve executable name and path in Operating System - HP-UX

C/C++: how to retrieve executable name and path

Peter Hug — Thu, 16 Dec 2004 16:00:45 GMT

In Windows I can use the api GetModuleFileName() and in Linux I can make a call to readlink("/proc/self/exe", ...) and realpath(...) to get these details at runtime, but what can I use in HP-UX?

While I could work this out programmatically using argv[0] and the PATH environment variable, this is not suitable as I need the info during static initialisation. However, if there was a way to access the commandline arguments before entering main() this would be an option.

Of course, even better would be a portable way to doing this - but for now I'd be wrapped if I had a reliable way in HP-UX.

Re: C/C++: how to retrieve executable name and path

Dan_334 — Fri, 17 Dec 2004 00:17:23 GMT

i dont understand what you are trying to say???????

Re: C/C++: how to retrieve executable name and path

Ermin Borovac — Fri, 17 Dec 2004 00:29:39 GMT

From http://www.faqs.org/faqs/unix-faq/programmer/faq/

1.14 How can I find a process' executable file?
===============================================

This would be a good candidate for a list of `Frequently Unanswered
Questions', because the fact of asking the question usually means that the
design of the program is flawed. :-)

You can make a `best guess' by looking at the value of `argv[0]'. If this
contains a `/', then it is probably the absolute or relative (to the
current directory at program start) path of the executable. If it does
not, then you can mimic the shell's search of the `PATH' variable, looking
for the program. However, success is not guaranteed, since it is possible
to invoke programs with arbitrary values of `argv[0]', and in any case the
executable may have been renamed or deleted since it was started.

If all you want is to be able to print an appropriate invocation name with
error messages, then the best approach is to have `main()' save the value
of `argv[0]' in a global variable for use by the entire program. While
there is no guarantee whatsoever that the value in `argv[0]' will be
meaningful, it is the best option available in most circumstances.

The most common reason people ask this question is in order to locate
configuration files with their program. This is considered to be bad form;
directories containing executables should contain *nothing* except
executables, and administrative requirements often make it desirable for
configuration files to be located on different filesystems to executables.

A less common, but more legitimate, reason to do this is to allow the
program to call `exec()' *on itself*; this is a method used (e.g. by some
versions of `sendmail') to completely reinitialise the process (e.g. if a
daemon receives a `SIGHUP').

Re: C/C++: how to retrieve executable name and path

Peter Hug — Fri, 17 Dec 2004 02:28:17 GMT

> This would be a good candidate for a list of
> `Frequently Unanswered Questions', because
> the fact of asking the question usually
> means that the design of the program is
> flawed. :-)

What a lousy argument. Good software offers choices, regardless of whether or not someone likes a certain choice. I will argue that those who make such silly statements just deny the existence of any flaws in Unix.

In the meantime I found the answer:

#include
#include
#include

int main ()
{
char *szExecPath;
char szFullPath[PATH_MAX+1];

if ((szExecPath = getenv("_")) == NULL)
{
fprintf(stderr, "Could not read path from environment.\n");
exit(EXIT_FAILURE);
}

if (realpath(szExecPath, szFullPath) == NULL)
{
fprintf(stderr, "Error resolving full path.\n");
exit(EXIT_FAILURE);
}

printf("Path is: %s\n", szExecPath);
printf("Full path is: %s\n", szFullPath);

return 0;
}

Re: C/C++: how to retrieve executable name and path

Thomas Bianco — Fri, 17 Dec 2004 08:26:50 GMT

you might take a look at the Gnu programs that run differently based on how they are called. GNU Grep (aka eGrep fGrep etc...)and gzip (aka gunzip gzcat) have been ported to HPUX and exhibit this beheviour.

i can see that a program looking for it's config files based on how this was called could be bad planning, but there are legitimate reasons to know how this was exec'd.

from a totally academic perspective, any program should be able to run without knowing anything about itself, but that's not to say it's always practicable to do this.