eigenen Pfad unter Linux ermitteln

alterbro

Wie kann man unter Linux den Programmpfad ermitteln?

SeppJ

Kurze Antwort: Geht nicht (zumindest nicht allgemein für jeden vorstellbaren Fall).

Hilfreiche Antwort: Was möchte dein Programm mit dieser Information machen? Das was du erreichen möchtest, lässt sich bestimmt auch anders (und besser!) erreichen.

alterbro

naja, irgendwo müssen ja texturen, maps, modelle, profile usw gespeichert werden.

und nach meiner erfahrung ist das in demselben ordner wie exe datei, order ist das in Linux anders, ich arbeite noch nicht alzu lange mit Linux.

also wo speicher ich jetzt das ganze zeug?

SeppJ

Du denkst Windows.

Ich rate zu folgendem Link, um erst einmal ein paar Grundlagen aufzubauen, dann kannst du deine Fragen sicherlich selber beantworten:
Google: linux folders explained

alterbro

wenn du wüsstest wie oft ich den satz gehört hab.

okay, danke seh ich mir mal an.

SeppJ

alterbro schrieb:

wenn du wüsstest wie oft ich den satz gehört hab.

Sind nun einmal zwei verschiedene Welten. Wobei Windows sich mit den Profilordnern zumindest ein bisschen dem Unixsystem angenähert hat. Wobei leider immer noch viele Programme versuchen, Spielstände und ähnliches in ihrem Verzeichnis zu speichern anstatt im Nutzerprofil .

(Das war ein versteckter Tipp für den richtigen Speicherort für Profile )

alterbro

okay dann also bei einem spiel

Programm->usr/games
Maps,Texturen,Skins...->usr/share/games/.game
Profile,Highscores,Favoriten->/home/benutzer/.game

stimmt das?

SeppJ

/usr/games ist ungewöhnlich, aber im Prinzip richtig (viele Spiele sehen sich als selber als "normales" binary). Der Rest passt auch.

Natürlich kommt erschwerend hinzu, dass manche Distributionen wieder ihr eigenes Süppchen kochen, aber bei den meisten fährst du hiermit ganz gut.

Allgemein sollten die Pfade natürlich nicht hardcoded im Quellcode stehen, sondern vom Installationsprefix abhängig sein.

alterbro

Ok dann werd ich wohl mal googeln mpüssen wie man an den namen des Angemeldeten Benutzers kommt, ein installationspaket erstellt und was ein Installationsprefix ist.
danke für den denkanstoss.

nevermore

alterbro schrieb:

Maps,Texturen,Skins...->usr/share/games/.game

Hier muss der Punkt noch weg. Den benutzt man nur für Sachen, die in /home/benutzer landen.

alterbro

ok, danke

SeppJ

alterbro schrieb:

Ok dann werd ich wohl mal googeln mpüssen wie man an den namen des Angemeldeten Benutzers kommt,

$HOME, ~, usw.

ein installationspaket erstellt

klassisch wäre configure, make, make install (dafür zur Vereinfachung GNU Autotools, CMake, o.Ä. benutzen), wenn es ausgefallener sein soll noch deb- oder rpm-Pakete für populäre Distributionen.

und was ein Installationsprefix ist.

Siehe configure.

Ich bin aber ehrlich gesagt etwas überrascht: Das sind eigentlich absolute Grundlagen, wenn man irgendwie auch nur entfernt mal was mit Softwareinstallation in Linux zu tun hatte (und nicht alles dem Distributor überlassen hat). Du wirst die Lernkurve höchstwahrscheinlich ziemlich steil finden (ich wage sogar zu sagen: zu steil), wenn du gleich selber Software auf diese Weise anbieten willst, ohne eigene Erfahrung in der Benutzung zu haben oder den Sinn dahinter verstanden zu haben.

alterbro

ja ich weiss, ich hab lang mit windows gearbeitet, und hätte nicht gedacht, das es ein so enormes umdenken ist, aber irgendwo muss ich ja anfangen.

Aber danke für deine Hilfe, ich werde selbst noch ein wenig aufarbeiten, bis ich die Basics draufhabe.

DrGreenthumb

SeppJ schrieb:

Kurze Antwort: Geht nicht (zumindest nicht allgemein für jeden vorstellbaren Fall).

Hilfreiche Antwort: Was möchte dein Programm mit dieser Information machen? Das was du erreichen möchtest, lässt sich bestimmt auch anders (und besser!) erreichen.

Die Frage war ja wie das unter Linux funktioniert. Natürlich geht das.

Kurze Antwort: dirname $(readlink /proc/$ PID/exe)

Hilfreiche Antwort: Das /proc/-Verzeichnis enthält für jeden Prozess ein Unterverzeichnis in dem ein Softlink existiert, der auf die Exe-Datei zeigt. In dem String findet man das Verzeichnis in dem die exe liegt.

Christoph

DrGreenthumb schrieb:

Die Frage war ja wie das unter Linux funktioniert. Natürlich geht das.

Kurze Antwort: dirname $(readlink /proc/$ PID/exe)

Das gibt dir bei interpretierten Programmen nur den Pfad zum Interpreter. Das funktioniert also nicht allgemein, genau wie SeppJ gesagt hat. Und ich würde auch nicht die Hand ins Feuer legen, dass das auf allen Linux-Distributionen so überhaupt funktionieren kann.

dirname wird übrigens einen Fehler ausgeben, wenn readlink einen Pfad liefert, der Leerzeichen enthält, weil bash dann word splitting macht. Einen Ausdruck wie $() muss man in Bash fast immer mit "" quoten, wenn man ihn direkt als Parameter für einen anderen Befehl verwendet.

DrGreenthumb

Christoph schrieb:

DrGreenthumb schrieb:

Die Frage war ja wie das unter Linux funktioniert. Natürlich geht das.

Kurze Antwort: dirname $(readlink /proc/$ PID/exe)

Das gibt dir bei interpretierten Programmen nur den Pfad zum Interpreter. Das funktioniert also nicht allgemein, genau wie SeppJ gesagt hat. Und ich würde auch nicht die Hand ins Feuer legen, dass das auf allen Linux-Distributionen so überhaupt funktionieren kann.

ich habe ja auch exe-Datei geschrieben. Abkürzung für "ELF 32-bit LSB executable"
Bei einer interpretierten Sprache gibts idR. andere Möglichkeiten.

Das bash-Beispiel geht garantiert nicht auf allen System und war mehr als Pseudo-Code gedacht. Wer wirklich Bash schreiben will muss das erkennen.
Den Softlink in /proc kann man aber sicher annehmen. Aber OK: man müsste vielleicht dem Benutzer eine Möglichkeit geben, dass ermittelte Verzeichnis zu konfigurieren.

Wie auch immer. Einfach zu sagen "geht nicht" wollte ich so nicht stehenlassen.

SeppJ

Deswegen steht da ja auch nicht nur "geht nicht" sondern mehr.

Christoph

DrGreenthumb schrieb:

Den Softlink in /proc kann man aber sicher annehmen.

Kann man das? Ich kenn mich mit den Sicherheits-Erweiterungen, die es so für Linux gibt, nicht gut aus, aber bist du sicher, dass z.B. SELinux den Lesezugriff auf /proc/pid/exe nicht einfach einschränken kann?

Ein anderer Punkt ist, dass /proc/pid/exe auf eine temporäre Datei wie /tmp/foo zeigen könnte, die schon lange nicht mehr im Dateisystem existiert.

Es funktioniert also schon, aber ist halt so wackelig, dass es außer in Ausnahmefällen keine geeignete Lösung ist. Nur wenn ich genau weiß, unter welchen Bedingungen das funktioniert und unter welchen nicht, würde ich das nehmen.

edit: Bei vielen interpretierten Sprachen kann das Ermitteln des Skriptnamens prinzipiell gar nicht funktionieren, und zwar einfach aus dem Grund, dass man auch Skripte ausführen kann, die man per stdin in den Interpreter piped. Dann sieht der Interpreter außer "stdin" gar keinen Skriptnamen.

nman

Das wird ziemlich haeufig gefragt; hat vielleicht jemand Lust, die hier gesammelten Erkenntnisse in einem FAQ-tauglichen Post zusammenzufassen?

DrGreenthumb

Christoph schrieb:

DrGreenthumb schrieb:

Den Softlink in /proc kann man aber sicher annehmen.

Kann man das? Ich kenn mich mit den Sicherheits-Erweiterungen, die es so für Linux gibt, nicht gut aus, aber bist du sicher, dass z.B. SELinux den Lesezugriff auf /proc/pid/exe nicht einfach einschränken kann?

oder /proc ganz wegnehmen. Dann gehts auch nicht...

Man muss ja immer abwägen wovon man abhängig sein möchte. Eine andere Möglichkeit, die dann vermutlich auch unter BSD oder so funktioniert, ist zu der exe ein Shellscript zu legen was z.B. eine Umgebungsvariable setzt und das stattdessen aufzurufen:

#/bin/bash
export MY_PROGRAM_DIRECTORY="$(dirname "$0")"
exec $MY_PROGRAM_DIRECTORY/prog "@"

meine so machen es auch openoffice & co.

Das funktioniert natürlich auch nicht wenn der Benutzer anfängt das Program in einen Scriptinterpreter zu pipen oder das Verzeichnis löscht, wo das Programm seine Daten lesen will