Eine Login-Shell ist grob gesagt eine, in die man sich einloggt, also z.B. die, in die einen das login der Linux-Konsole wirft. Die Shells in den xterms, die man im Fenster-Manager startet, sind keine Login-Shells. Die ~/.profile wird prinzipiell nur bei Login-Shell-Starts eingelesen.
Eine interaktive Shell ist eine mit angebundenem manuell bedienbarem Terminal. Shell-Skripte werden in nicht-interaktiven Shells ausgeführt.
Bash als Login-Shell sucht das Home-Verzeichnis in Reihenfolge nach ~/.bash_profile, ~/.bash_login, ~/.profile ab und liest nur die erste gefundene, findet Bash z.B. ~/.bash_profile, liest es nur diese und den Rest nicht. Als Nicht-Login-Shell liest Bash die ~/.bashrc.
Eine sinnvolle Strategie scheint, für Bashismen eine ~/.bashrc und eine ~/.bash_profile anzulegen, wobei letztere für Login-Shell-spezifische Bashismen zuständig sei und erstere aufruft, und außerdem eine ~/.profile für Login-spezifische Nicht-Bashismen, die ebenfalls aus ~/.bash_profile aufzurufen sei. Und Non-Login-Shells, die nicht Bash sind, was lesen die statt ~/.bashrc ein? Die man page von dash empfiehlt, eine ~/.shinit anzulegen und in ~/.profile ein 'ENV=$HOME/.shinit; export ENV' zu schreiben, da dash als Nicht-Login-Shell immerhin zum Start noch die in ENV genannte Datei ausführe; dies ist wohl sogar erwartetes Verhalten von POSIX-Shells. (Bash wiederum hält sich nicht dran, außer wenn explizit im POSIX-Kompatibilitäts-Modus gestartet, liest also nicht die Datei im ENV-Pfad ein. Eine ~/.bashrc, die das Einlesen von ~/.shinit explizit anweist, löst das Problem.)
Keine Kommentare zu dieser Seite.
Kommentar-Schreiben derzeit nicht möglich: Kein Captcha gesetzt.