eigenen Pfad unter Linux ermitteln
-
wenn du wüsstest wie oft ich den satz gehört hab.
okay, danke seh ich mir mal an.
-
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 )
-
okay dann also bei einem spiel
Programm->usr/games
Maps,Texturen,Skins...->usr/share/games/.game
Profile,Highscores,Favoriten->/home/benutzer/.gamestimmt das?
-
/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.
-
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.
-
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.
-
ok, danke
-
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.
-
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.
-
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 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.
-
DrGreenthumb schrieb:
Die Frage war ja wie das unter Linux funktioniert. Natürlich geht das.
Kurze Antwort: dirname 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.
-
Christoph schrieb:
DrGreenthumb schrieb:
Die Frage war ja wie das unter Linux funktioniert. Natürlich geht das.
Kurze Antwort: dirname 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.
-
Deswegen steht da ja auch nicht nur "geht nicht" sondern mehr.
-
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.
-
Das wird ziemlich haeufig gefragt; hat vielleicht jemand Lust, die hier gesammelten Erkenntnisse in einem FAQ-tauglichen Post zusammenzufassen?
-
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