Teil1: Programme Pfade und warum das Ausführen oft nicht klappt.

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Hinweis: In dem Thema Teil1: Programme Pfade und warum das Ausführen oft nicht klappt. gibt es 2 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Teil1: Programme Pfade und warum das Ausführen oft nicht klappt.

    Linux ist eine riesig große Familie, deren Gene letztlich von Unix stammen.
    Diese Familie ist so groß, dass es schon seit einiger Zeit nötig ist, grundlegende Dinge per Konvention zu normieren.
    Die LSB (LinuxStandardBase ) ist ein solches Regelwerk. Dort wurde auch der FHS (FileHierarchyStandard) definiert.
    Diesen FHS sollte man zumindest oberflächlich kennen. Und dazu einmal man hier(archy) lesen.

    Hier will ich jedoch nur einen sehr kleinen Teil davon näher beleuchten.
    Nämlich, wie ein Programm oder Script in einem Linux ausgeführt wird.
    Und ich beschränke mich auf die Grundprinzipien, die für Otto-Normal-Linuxer wesenziell sind.

    Abgesehen vom FHS, der ja nur beschreibt, wie welches Verzeichnis zu verwenden ist, sind noch zwei Themenbereiche wichtig:
    Einmal das Konzept des Pfades und dann ein wenig die Prozessstruktur eines laufenden Programmes/Scriptes.

    Zuerst beschreibe ich die Basics der Prozessstruktur, da dieses Wissen dann auch das Konzept des Pfades leichter verstehen lässt:
    Unter Linux gilt everything is a file
    Es gibt unter den unzähligen Dateisysteme auch einige sogenannte Pseudodateisysteme.
    Alles was sich unter dem Pfad /proc findet, ist ein Blick in den Kernel, wie er gerade am Arbeiten ist. Das Pseudodateisystem /proc stellt uns interne Kerneldatenstrukturen so da, als wären es ganz normale Dateien und Verzeichnisse.
    Und die können wir mit unseren "normalen" Programmen dann einfach lesen und zum Teil sogar schreiben.
    Wenn wir also in irgendeine Datei von /proc schreiben, schreiben wir tatsächlich direkt in irgendwelche Datenstrukturen des Kernels, nicht in eine Datei.
    Falls wir genügend Rechte haben. Manche Sachen gehen Otto-Normal-User einfach nichts an.

    Jedes Programm, das gerade unter Linux läuft, ist erst einmal ein Prozess, der als genau definierte Datenstruktur im RAM liegt. Dazu gehören natürlich das Programm/Script selbst, seine Daten und dann noch ein Sicherheitskontext, bestimmte Runtimeparameter und dergleichen mehr. Verwaltet werden alle laufenden Prozesse ohne Ansehens der Privilege mit einer PID, der ProcessID, die lediglich eine meist zwei Bytes große Integer- Zahl ist. (wie die genau definiert wird, wird zur Compilezeit in der limits.h festgelegt; falls ich das noch korrekt in Erinnerung habe..,lieber nachgucken...)
    Die werden einfach der Reihe nach hochgezählt, und dem jeweilig nächsten aufgerufenem Program zugeordnet. Endet das Programm, wird diese PID wieder frei und später erneut für ein wahrscheinlich völlig anderes Programm verwendet.

    Damit alle Programme sauber laufen können, gibt es also in /proc für JEDEN laufenden Prozess ein eigenes Verzeichnis. (Und diverse quasi "zweckgebundene" Unterverzeichnisse).
    Und diese Verzeichnisse lauten schlicht /proc/<pid>. Es gibt also für jeden laufenden Prozess ein Unterverzeichnis das die eigene PID als Namen hat.

    Programme können aus vielen Teilen bestehen. Und viele lesen irgendwelche Daten und Konfigurationsdaten zur Laufzeit aus irgendwelchen Dateien. Die müssen vom Kernel gefunden werden können. Deshalb gibt es das sogenannte cwd (CurrentWorkingDirectory). Und das ist natürlich auch im /proc/<pid> zu finden. Es ist dort ein Link namens cwd auf das tatsächliche Verzeichnis.
    (Ein Link kostet außer einem Eintrag in der inode- Tabelle keinerlei Speicherplatz; Links werden vom kernel und vielen Programmen unter der Haube sehr, sehr, häufig verwendet. Auch ein ganz wesentliches Konzept)

    Alles, was dieses Programm lesen oder ausführen will, wird, wenn man relative Pfade verwendet, von diesem cwd aus gesucht.
    Blöd, dass jedes Programm/Script dieses cwd nach Belieben ändern kann, was das folgende Miniscript ganz hübsch darstellt:
    Vorbemerkung: readlink ist ein Programm, das seinen Parameter, nämlich einen Pfad/Dateinamen liest, und dann über fast beliebig viele Links hinweg sich zu der tatsächlichen Datei durchhangelt um dann dessen vollständigen (absoluten) Pfad auszugeben. Das $$ ist eine Expansion der besonderen Shellvariablen names $. Das erste Dollarzeichen bewirkt, dass der Inhalt dieser Variablen $ ausgegeben wird. Die Bash parst das Kommando und ersetzt das $$ mit der jeweils gültigen PID. Anstelle von /proc/$$/cwd wird also zum Beispiel /proc/19643/cwd ausführt. In der Variablen $ steht -per definitionem- die PID der aktuellen Shell.

    Shell-Script

    1. #!/bin/bash
    2. echo in /proc/$$/cwd findet sich jetzt:
    3. readlink /proc/$$/cwd
    4. echo _______________
    5. echo
    6. cd /
    7. echo in /proc/$$/cwd findet sich jetzt:
    8. readlink /proc/$$/cwd
    9. echo _______________
    10. echo
    11. cd /usr
    12. echo in /proc/$$/cwd findet sich jetzt:
    13. readlink /proc/$$/cwd
    14. echo _______________
    15. echo
    16. cd
    17. echo nach \"cd \" finden wir mit \"readlink\" wieder in:
    18. echo "(ein schlichtes \"cd\" ist die Kurzform von \"cd $HOME\")"
    19. readlink /proc/$$/cwd
    Alles anzeigen
    Das Ding einfach in eine Datei kopieren und mit bash <dieseNeueDatei> aufrufen. (Oder mit chmod +x <dieseNeueDatei> ausführbar machen, und dann mit ./<dieseNeueDatei> aufrufen. Das zeigt sehr schön, dass sich dieses cwd wirklich zur Laufzeit beliebig ändern lässt.


    Damit wäre der erste Teil geschafft.
    Im zweiten werde ich die PATH Variable und den Unterschied zwischen absolutem und relativen Pfad erklären.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 104042 haftet ausdrücklich der jeweilige Autor: Berichtigung