Details zum Start von Bash

Wenn Sie diese Seite in der Suche gefunden haben, versuchen Sie wahrscheinlich, ein Problem mit dem Start von bash zu lösen.

Möglicherweise wird in Ihrer Umgebung die Umgebungsvariable für bash nicht gesetzt und Sie verstehen nicht, warum. Vielleicht haben Sie etwas in verschiedene bash-Startdateien oder Profile gesteckt oder in alle Dateien nach dem Zufallsprinzip, bis es funktioniert hat.

In jedem Fall besteht der Sinn dieser Notiz darin, das Verfahren zum Start von bash so einfach wie möglich darzulegen, damit Sie die Probleme bewältigen können.

Diagramm

Dieses Flussdiagramm fasst alle Prozesse beim Start von bash zusammen.

Nun betrachten wir jede Komponente genauer.

Login-Shell?

Zuerst müssen Sie auswählen, ob Sie sich in einer Login-Shell (Login-Shell) befinden oder nicht.

Eine Login-Shell ist die erste Shell, in die Sie beim Einloggen in ein interaktives Sitzung gelangen. Die Login-Shell erfordert keine Eingabe von Benutzername und Passwort. Sie können den Start der Login-Shell erzwingen, indem Sie das Flag hinzufügen: --login beim Aufruf bash, zum Beispiel:

bash --login

Die Login-Shell konfiguriert die grundlegende Umgebung beim ersten Start der bash-Shell.

Interaktiv?

Dann bestimmen Sie, ob die Shell interaktiv ist oder nicht.

Das lässt sich durch das Vorhandensein der Variablen überprüfen: PS1 (setzt die Eingabefunktion fest):

if [ "${PS1-}" ]; then
  echo interaktiv
else
  echo nicht-interaktiv
fi

Oder überprüfen Sie, ob das Attribut -igesetzt ist, mit der speziellen Minus-Variable - in bash, zum Beispiel:

$ echo $-

Wenn in der Ausgabe das Zeichen ivorhanden ist, dann ist die Shell interaktiv.

In der Login-Shell?

Wenn Sie sich in einer Login-Shell befinden, sucht bash nach der Datei /etc/profile und führt sie aus, wenn sie existiert.

Danach sucht bash in folgender Reihenfolge nach einer dieser drei Dateien:

~/ .bash_profile
~/ .bash_login
~/ .profile

Wenn es eine findet, führt es diese aus und überspringt die anderen.

In der interaktiven Shell?

Wenn Sie sich in einer interaktiven Shell ohne Anmeldung (non-login shell) befinden, wird davon ausgegangen, dass Sie bereits in einer Login-Shell waren, die Umgebung konfiguriert wurde und geerbt wird.

In diesem Fall werden nacheinander die folgenden zwei Dateien ausgeführt, wenn sie existieren:

/etc/bash.bashrc
~/.bashrc

Keine der Optionen?

Wenn Sie sich weder in einer Login-Shell noch in einer interaktiven Shell befinden, ist Ihre Umgebung wirklich leer. Dies verursacht große Verwirrung (siehe unten zu Cron-Jobs).

In diesem Fall schaut bash auf die Variable BASH_ENV Ihre Umgebung und erstellt die entsprechende Datei, die dort angegeben ist.

Typische Schwierigkeiten und Faustregeln

Cron-Jobs

In 95 % der Fälle hängt das Debugging des Bash-Starts damit zusammen, dass der Cron-Job nicht wie erwartet funktioniert.

Dieser verdammte Job funktioniert einwandfrei, wenn ich ihn in der Kommandozeile ausführe, schlägt jedoch im Crontab fehl.

Hier drei Gründe:

• Cron-Jobs sind nicht interaktiv.
• Im Gegensatz zu Skripten in der Kommandozeile erben Cron-Jobs nicht die Umgebung der Shell.

Normalerweise merkt man nicht oder kümmert sich nicht darum, dass das Shell-Skript nicht interaktiv ist, da die Umgebung von der interaktiven Shell geerbt wird. Das bedeutet, dass alles PATH und Alias so konfiguriert ist, wie man es erwartet.

Deshalb muss man häufig eine spezifische PATH Umgebungsvariable für den Cron-Job setzen, wie hier:

* * * * * PATH=${PATH}:/path/to/my/program/folder myprogram

Skripte, die sich gegenseitig aufrufen

Ein weiteres häufiges Problem, wenn Skripte versehentlich so konfiguriert sind, dass sie sich gegenseitig aufrufen. Zum Beispiel, /etc/profile auf den ~/.bashrc.

Das passiert normalerweise, wenn jemand versucht hat, einen Fehler zu beheben und es anscheinend funktioniert hat. Leider entstehen neue Probleme, wenn man diese verschiedenen Typen von Sitzungen trennen muss.

Docker-Image in der Sandbox

Um mit dem Start der Shell zu experimentieren, habe ich ein Docker-Image erstellt, das man für das Debugging des Shell-Starts in einer sicheren Umgebung verwenden kann.

Start:

$ docker run -n bs -d imiell/bash_startup
$ docker exec -ti bs bash

Die Dockerfile befindet sich hier.

Für ein erzwungenes Login und die Simulation einer Login-Shell:

$ bash --login

Zur Überprüfung der Variablen BASH_ENV:

$ env | grep BASH_ENV

Für das Debugging crontab wird jede Minute ein einfaches Skript ausgeführt (im /root/ascript):

$ crontab -l
$ cat /var/log/script.log

Quelle: habr.com