Programmatisches Abrufen des absoluten Pfads einer OS X-Befehlszeilen-App

Question 1

Unter Linux kann eine Anwendung ihren absoluten Pfad einfach durch Abfragen erhalten /proc/self/exe. Unter FreeBSD ist es komplizierter, da Sie einen sysctl-Aufruf aufbauen müssen:

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);

aber es ist noch völlig machbar. Ich kann jedoch keine Möglichkeit finden, dies unter OS X für eine Befehlszeilenanwendung zu bestimmen. Wenn Sie innerhalb eines App Bundles ausführen, können Sie dies durch Ausführen ermitteln [[NSBundle mainBundle] bundlePath]aber da Befehlszeilenanwendungen nicht in Bundles enthalten sind, hilft dies nicht.

(Hinweis: Beratung argv[0] ist keine vernünftige Antwort, da, wenn sie von einem Symlink gestartet wird, argv[0] wird dieser symbolische Link sein – nicht der endgültige Pfad zu der aufgerufenen ausführbaren Datei. argv[0] kann auch liegen, wenn eine dumme Anwendung eine verwendet exec() anrufen und vergessen, argv richtig zu initialisieren, was ich in freier Wildbahn gesehen habe.)

Question 2

Die Funktion _NSGetExecutablePath gibt einen vollständigen Pfad zur ausführbaren Datei zurück (GUI oder nicht). Der Pfad kann symbolische Links enthalten, “..” usw. aber die realpath Funktion kann verwendet werden, um diese bei Bedarf zu bereinigen. Sehen man 3 dyld für mehr Informationen.

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);

Das Geheimnis dieser Funktion besteht darin, dass der Darwin-Kernel den ausführbaren Pfad direkt nach dem auf den Prozessstapel legt envp -Array, wenn es den Prozess erstellt. Der Editor für dynamische Links dyld greift dies bei der Initialisierung und hält einen Zeiger darauf. Diese Funktion verwendet diesen Zeiger.

Question 3

Ich glaube, es gibt eine viel elegantere Lösung, die tatsächlich für jede PID funktioniert und auch den absoluten Pfad direkt zurückgibt:

#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;
}

Question 4

Sieht so aus, als ob die Antwort lautet, dass Sie es nicht tun können:

Ich versuche, so etwas wie die Funktionalität von lsof zu erreichen und eine ganze Reihe von Statistiken und Informationen über laufende Prozesse zu sammeln. Wenn lsof nicht so langsam wäre, würde ich gerne dabei bleiben.

Wenn Sie lsof neu implementieren, werden Sie feststellen, dass es langsam ist, weil es viel Arbeit macht.

Ich denke, das liegt nicht wirklich daran, dass lsof im Benutzermodus ist, sondern dass es den Adressraum einer Aufgabe durchsuchen muss, um nach Dingen zu suchen, die von einem externen Pager unterstützt werden. Gibt es eine schnellere Möglichkeit, dies zu tun, wenn ich mich im Kernel befinde?

Nein. lsof ist nicht dumm; es tut, was es tun muss. Wenn Sie nur eine Teilmenge seiner Funktionalität benötigen, sollten Sie in Betracht ziehen, mit der lsof-Quelle (die verfügbar ist) zu beginnen und sie auf Ihre Anforderungen zuzuschneiden.

Aus Neugier ist p_textvp überhaupt verwendet? Es sieht so aus, als wäre es auf das der Eltern eingestellt p_textvp in kern_fork (und dann freigelassen werden??), aber es wird in keinem von ihnen berührt kern_exec‘s Routinen.

p_textvp ist nicht benutzt. In Darwin ist die proc nicht die Wurzel des Adressraums; die aufgabe ist. Es gibt kein Konzept des “vnode” für den Adressraum einer Aufgabe, da er nicht unbedingt anfänglich durch Zuordnen eines solchen gefüllt wird.

Wenn exec p_textvp füllen würde, würde es zu der Annahme führen, dass alle Prozesse von einem vnode unterstützt werden. Dann würden Programmierer annehmen, dass es möglich war, einen Pfad zum vnode zu erhalten, und von dort aus ist es ein kurzer Sprung zu der Annahme, dass der aktuelle Pfad zum vnode der Pfad ist, von dem aus er gestartet wurde, und dass die Textverarbeitung auf der Zeichenfolge erfolgt könnte zum Namen des Anwendungspakets führen, was ohne erhebliche Strafe unmöglich zu garantieren wäre.

—Mike Smith, Darwin Drivers-Mailingliste

Question 5

Das ist spät, aber [[NSBundle mainBundle] executablePath] funktioniert gut für nicht gebündelte Befehlszeilenprogramme.

Question 6

Ich denke, es gibt keinen garantierten Weg. Wenn argv[0] ein Symlink ist, dann könnten Sie readlink() verwenden. Wenn der Befehl über den $PATH ausgeführt wird, kann man Folgendes versuchen: search(getenv(“PATH”)), getenv(“_”), dladdr()

Question 7

Warum nicht einfach realpath(argv[0], actualpath);? Richtig, realpath hat einige Einschränkungen (dokumentiert in der Handbuchseite), aber es handhabt symbolische Links gut. Getestet auf FreeBSD und 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);
}

Wenn das Programm über PATH gestartet wird, siehe die Lösung von Pixelbeat.

Question 8

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

GetProcessBundleLocation scheint zu funktionieren.