29

On Linux, an application can easily get its absolute path by querying /proc/self/exe. On FreeBSD, it's more involved, since you have to build up a sysctl call:

int mib[4];
mib[0] = CTL_KERN;
mib[1] = KERN_PROC;
mib[2] = KERN_PROC_PATHNAME;
mib[3] = -1;
char buf[1024];
size_t cb = sizeof(buf);
sysctl(mib, 4, buf, &cb, NULL, 0);

but it's still completely doable. Yet I cannot find a way to determine this on OS X for a command-line application. If you're running from within an app bundle, you can determine it by running [[NSBundle mainBundle] bundlePath], but because command-line applications are not in bundles, this doesn't help.

(Note: consulting argv[0] is not a reasonable answer, since, if launched from a symlink, argv[0] will be that symlink--not the ultimate path to the executable called. argv[0] can also lie if a dumb application uses an exec() call and forget to initialize argv properly, which I have seen in the wild.)

Cœur
  • 37,241
  • 25
  • 195
  • 267
Benjamin Pollack
  • 27,594
  • 16
  • 81
  • 105
  • 1
    Reading argv[0] is the solution and nothing in this thread yet convinced me. – bortzmeyer Apr 29 '09 at 07:49
  • 13
    @bortzmeyer:consider `execl("/home/hacker/.hidden/malicious", "/bin/ls", "-s", (char *)0);` - the value of 'argv[0]` is `"/bin/ls"` but that is nothing to do with the name of the executable. – Jonathan Leffler May 24 '11 at 06:23

7 Answers7

61

The function _NSGetExecutablePath will return a full path to the executable (GUI or not). The path may contain symbolic links, "..", etc. but the realpath function can be used to clean those up if needed. See man 3 dyld for more information.

char path[1024];
uint32_t size = sizeof(path);
if (_NSGetExecutablePath(path, &size) == 0)
    printf("executable path is %s\n", path);
else
    printf("buffer too small; need size %u\n", size);

The secret to this function is that the Darwin kernel puts the executable path on the process stack immediately after the envp array when it creates the process. The dynamic link editor dyld grabs this on initialization and keeps a pointer to it. This function uses that pointer.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
mark4o
  • 58,919
  • 18
  • 87
  • 102
36

I believe there is much more elegant solution, which actually works for any PID, and also returns the absolute path directly:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <libproc.h>

int main (int argc, char* argv[])
{
    int ret;
    pid_t pid; 
    char pathbuf[PROC_PIDPATHINFO_MAXSIZE];

    pid = getpid();
    ret = proc_pidpath (pid, pathbuf, sizeof(pathbuf));
    if ( ret <= 0 ) {
        fprintf(stderr, "PID %d: proc_pidpath ();\n", pid);
        fprintf(stderr, "    %s\n", strerror(errno));
    } else {
        printf("proc %d: %s\n", pid, pathbuf);
    }

    return 0;
}
Alen Stojanov
  • 1,178
  • 10
  • 14
  • 4
    Thanks! One thing though, using OS X 10.8.5, this didn't work for me without: #include – original_username Oct 10 '13 at 20:28
  • The best solution I could ever get. Very clean work! – Pal Oct 07 '16 at 18:12
  • This implies that _NSGetExecutablePath doesn't work for all PIDs - can you elaborate on how so? I cannot find a reference elsewhere that states this. – hpm Apr 26 '18 at 15:50
  • @hyperum does `_NSGetExecutablePath` work for PID too? If so, can you provide an example to further improve the accepted answer? – tresf Apr 14 '20 at 16:27
  • @hpm Perhaps Alen was just referring to the fact that `proc_pidpath` can be called to retrieve information about an arbitrary process from any process (since it has a pid parameter), while `_NSGetExecutablePath` only gives you information about the current process. – Burcea Bogdan Madalin Dec 27 '21 at 16:30
4

Looks like the answer is that you can't do it:

I'm trying to achieve something like lsof's functionality and gather a whole bunch of statistics and info about running processes. If lsof weren't so slow, I'd be happy sticking with it.

If you reimplement lsof, you will find that it's slow because it's doing a lot of work.

I guess that's not really because lsof is user-mode, it's more that it has to scan through a task's address space looking for things backed by an external pager. Is there any quicker way of doing this when I'm in the kernel?

No. lsof is not stupid; it's doing what it has to do. If you just want a subset of its functionality, you might want to consider starting with the lsof source (which is available) and trimming it down to meet your requirements.

Out of curiosity, is p_textvp used at all? It looks like it's set to the parent's p_textvp in kern_fork (and then getting released??) but it's not getting touched in any of kern_exec's routines.

p_textvp is not used. In Darwin, the proc is not the root of the address space; the task is. There is no concept of "the vnode" for a task's address space, as it is not necessarily initially populated by mapping one.

If exec were to populate p_textvp, it would pander to the assumption that all processes are backed by a vnode. Then programmers would assume that it was possible to get a path to the vnode, and from there it is a short jump to the assumption that the current path to the vnode is the path from which it was launched, and that text processing on the string might lead to the application bundle name... all of which would be impossible to guarantee without substantial penalty.

Mike Smith, Darwin Drivers mailing list

Grisha Levit
  • 8,194
  • 2
  • 38
  • 53
Brian Campbell
  • 322,767
  • 57
  • 360
  • 340
  • I really, really hate accepting answers that say, "You can't," but that quote certainly seems to put the nail in my question's coffin quite painfully. – Benjamin Pollack Apr 28 '09 at 22:13
  • 1
    Yeah, I hated giving the answer, too. I spent a while on a wild goose chase, trying to see if I could figure out how to get the information out of p_textvp, before I discovered this. – Brian Campbell Apr 28 '09 at 22:38
3

This is late, but [[NSBundle mainBundle] executablePath] works just fine for non-bundled, command-line programs.

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
2

There is no guaranteed way I think. If argv[0] is a symlink then you could use readlink(). If command is executed through the $PATH then one could try some of: search(getenv("PATH")), getenv("_"), dladdr()

pixelbeat
  • 30,615
  • 9
  • 51
  • 60
  • That will cover many cases, but still fails in the case you were launched by an application that neglected to initialize argv[0] properly--which, from personal experience, applies to a disturbing number of them. – Benjamin Pollack Apr 28 '09 at 21:22
  • Can you give an example of such an application? It is not the application which initializes argv, it's the libc and the application would need to do something very special to scramble argv[0]. – bortzmeyer Apr 29 '09 at 07:48
  • 3
    I can't give an example of an application off the top of my head that gets it wrong, but all they have to do to screw up argv[0] is forget to set it properly when invoking an application via one of the exec* calls. libc would only get involved if invoking the application via system(). – Benjamin Pollack Apr 29 '09 at 15:16
0

Why not simply realpath(argv[0], actualpath);? True, realpath has some limits (documented in the manual page) but it handles symbolic links fine. Tested on FreeBSD and Linux

    % ls -l foobar 
    lrwxr-xr-x  1 bortzmeyer  bortzmeyer  22 Apr 29 07:39 foobar -> /tmp/get-real-name-exe

    % ./foobar 
    My real path: /tmp/get-real-name-exe
#include <limits.h>
#include <stdlib.h>
#include <stdio.h>
#include <libgen.h>
#include <string.h>
#include <sys/stat.h>

int
main(argc, argv)
    int             argc;
    char          **argv;
{
    char            actualpath[PATH_MAX + 1];

    if (argc > 1) {
        fprintf(stderr, "Usage: %s\n", argv[0]);
        exit(1);
    }
    realpath(argv[0], actualpath);
    fprintf(stdout, "My real path: %s\n", actualpath);
    exit(0);
}

If the program is launched via PATH, see pixelbeat's solution.

bortzmeyer
  • 34,164
  • 12
  • 67
  • 91
  • This fails when a dumb program invokes you via an exec* call and improperly initializes the argv structure so that argv[0] is either just the executable name (i.e., not the full path) or flat-out wrong (absent, null string, or what have you). – Benjamin Pollack Apr 29 '09 at 15:18
  • 1
    If argv[0] is not the full path, no problem, realpath() will handle it. If it is empty or NULL, well, that's the fault of the caller, not of my program :-) – bortzmeyer Apr 29 '09 at 18:24
  • @BenjaminPollack: There's nothing remotely improper about the former if the executable is in `$PATH`! – SamB Feb 13 '12 at 01:59
0

http://developer.apple.com/documentation/Carbon/Reference/Process_Manager/Reference/reference.html#//apple_ref/c/func/GetProcessBundleLocation

GetProcessBundleLocation seems to work.

  • It works, provided your application is a GUI application launched via the Finder and links against Carbon. In that case, though, `[[NSBundle mainBundle] bundlePath]` would work, too--and avoid creating the `FSRef` and locating the process serial number. – Benjamin Pollack May 15 '09 at 14:56
  • @BenjaminPollack `[[NSBundle mainBundle] bundlePath]` also works for non-UI applications that are just a single binary as long as they link against `Foundation`. If your app just links against `CoreFoundation`, you can use `CFBundle`. All bundle methods also work for a plain binary that is no bundle at all, though they may not always return useful info but they work for getting the executable path of your binary. – Mecki Sep 08 '15 at 14:56