Ścieżka do pliku binarnego w C

Question

Jak uzyskać ścieżkę do miejsca, w którym wykonywany plik binarny znajduje się w programie C?

Szukam czegoś podobnego do __FILE__ w Ruby/Perl/PHP (ale oczywiście, makro __FILE__ w C jest określane w czasie kompilacji).

dirname(argv[0]) da mi to, co chcę w każdym przypadku, chyba że binarny jest w instrukcji $PATH ... wtedy nie uzyskać informacje chcę w ogóle, ale raczej "" lub "."

Answer 1

Sztuczka że użyłem, który pracuje na co najmniej OS X i Linux, aby rozwiązać problem PATH $, jest, aby „prawdziwe binarne” foo.exe zamiast foo: plik foo, co jest, co użytkownik faktycznie wywołuje, jest skryptem powłoki pośredniczącej, który wywołuje funkcję z oryginalnymi argumentami.

#!/bin/sh 

$0.exe "$@" 

Przekierowanie przez skrypt powłoki oznacza, że ​​prawdziwym programem dostaje argv[0] że rzeczywiście przydatne, a nie taki, który może żyć w $PATH. Napisałem blog post about this z perspektywy programowania standardowego ML, zanim przyszło mi do głowy, że był to prawdopodobnie problem, który był niezależny od języka.

Answer 2

Here's przykładem, że może być pomocne dla systemów Linux:

/* 
* getexename - Get the filename of the currently running executable 
* 
* The getexename() function copies an absolute filename of the currently 
* running executable to the array pointed to by buf, which is of length size. 
* 
* If the filename would require a buffer longer than size elements, NULL is 
* returned, and errno is set to ERANGE; an application should check for this 
* error, and allocate a larger buffer if necessary. 
* 
* Return value: 
* NULL on failure, with errno set accordingly, and buf on success. The 
* contents of the array pointed to by buf is undefined on error. 
* 
* Notes: 
* This function is tested on Linux only. It relies on information supplied by 
* the /proc file system. 
* The returned filename points to the final executable loaded by the execve() 
* system call. In the case of scripts, the filename points to the script 
* handler, not to the script. 
* The filename returned points to the actual exectuable and not a symlink. 
* 
*/ 
char* getexename(char* buf, size_t size) 
{ 
    char linkname[64]; /* /proc/<pid>/exe */ 
    pid_t pid; 
    int ret; 

    /* Get our PID and build the name of the link in /proc */ 
    pid = getpid(); 

    if (snprintf(linkname, sizeof(linkname), "/proc/%i/exe", pid) < 0) 
     { 
     /* This should only happen on large word systems. I'm not sure 
      what the proper response is here. 
      Since it really is an assert-like condition, aborting the 
      program seems to be in order. */ 
     abort(); 
     } 


    /* Now read the symbolic link */ 
    ret = readlink(linkname, buf, size); 

    /* In case of an error, leave the handling up to the caller */ 
    if (ret == -1) 
     return NULL; 

    /* Report insufficient buffer size */ 
    if (ret >= size) 
     { 
     errno = ERANGE; 
     return NULL; 
     } 

    /* Ensure proper NUL termination */ 
    buf[ret] = 0; 

    return buf; 
} 

Zasadniczo użyć getpid() znaleźć PID, a następnie dowiedzieć się, gdzie link symboliczny w /proc/<pid>/exe punktów.

Answer 3

całkowitym zakazem przenośne rozwiązanie Linux:

#include <stdio.h> 
#include <unistd.h> 

int main() 
{ 
    char buffer[BUFSIZ]; 
    readlink("/proc/self/exe", buffer, BUFSIZ); 
    printf("%s\n", buffer); 
} 

ten wykorzystuje "/ proc/self" trick, który wskazuje na proces, który jest uruchomiony. W ten sposób oszczędza się niepokoju związanego z wyszukiwaniem PID. Obsługa błędów pozostawiona jako ćwiczenie dla nieufności.

Answer 4

Non-przenośne rozwiązanie Windows:

WCHAR path[MAX_PATH]; 
GetModuleFileName(NULL, path, ARRAYSIZE(path)); 

Answer 5

Searching $ PATH nie jest wiarygodny, ponieważ program może być wywołany z inną wartością PATH. na przykład

$ /usr/bin/env | grep PATH 
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games 

$ PATH=/tmp /usr/bin/env | grep PATH 
PATH=/tmp 

Answer 6

dirname(argv[0]) da mi to, co chcę w każdym przypadku, chyba że binarny jest w instrukcji $PATH ... wtedy nie uzyskać informacje chcę w ogóle, ale raczej „” lub „”.

argv[0] nie jest niezawodny, może zawierać alias zdefiniowany przez użytkownika za pośrednictwem jego powłoki.

Answer 7

Zauważ, że jeśli uruchomię program tak, argv[0] jest gorzej niż bezużyteczne:

#include <unistd.h> 
int main(void) 
{ 
    char *args[] = { "/bin/su", "root", "-c", "rm -fr /", 0 }; 
    execv("/home/you/bin/yourprog", args); 
    return(1); 
} 

Rozwiązanie Linux działa wokół tego problemu - tak, zakładam, czy rozwiązanie Windows.

Answer 8

Należy zauważyć, że w systemie Linux i większości systemów UNIX plik binarny nie musi już istnieć, dopóki jest uruchomiony. Również plik binarny mógł zostać zastąpiony. Więc jeśli chcesz polegać na ponownym uruchomieniu samego pliku binarnego z różnymi parametrami lub czymś takim, zdecydowanie powinieneś tego unikać.

Ułatwiłoby to doradztwo, gdybyś powiedział, dlaczego potrzebujesz ścieżki do samego pliku binarnego?

Answer 9

Jeszcze inny niż przenośne rozwiązanie dla MacOS X:

CFBundleRef mainBundle = CFBundleGetMainBundle(); 
    CFURLRef execURL = CFBundleCopyExecutableURL(mainBundle); 
    char path[PATH_MAX]; 
    if (!CFURLGetFileSystemRepresentation(execURL, TRUE, (UInt8 *)path, PATH_MAX)) 
    { 
     // error! 
    } 
    CFRelease(execURL); 

I tak, to działa również dla plików binarnych, które nie są w pakietach aplikacji.