Detaillierter 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 Ihrem Bash-Umfeld die Umgebungsvariable nicht gesetzt, und Sie verstehen nicht, warum. Vielleicht haben Sie etwas in verschiedene Startdateien für Bash oder in Profile gesteckt oder einfach in alle Dateien hinein, bis es funktioniert hat.

So oder so, der Sinn dieser Notiz ist es, das Verfahren zum Starten von Bash so einfach wie möglich darzustellen, damit Sie Ihre Probleme bewältigen können.

Diagramm

Dieses Flussdiagramm fasst alle Prozesse beim Start von Bash zusammen.

Nun betrachten wir jeden Teil im Detail.

Login-Shell?

Zunächst müssen Sie entscheiden, ob Sie sich in einer Login-Shell befinden oder nicht.

Eine Login-Shell ist die erste Shell, in die Sie beim Einloggen für eine interaktive Sitzung gelangen. Eine Login-Shell benötigt keine Eingabe von Benutzernamen und Passwort. Sie können den Start einer Login-Shell erzwingen, indem Sie das Flag hinzufügen --login beim Aufruf bash, zum Beispiel:

bash --login

Die Login-Shell richtet die grundlegende Umgebung beim ersten Start der Bash-Shell ein.

Interaktiv?

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

Das können Sie überprüfen, indem Sie nach der Variable PS1 (Es stellt die Eingabefunktion ein):

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

Oder überprüfen, ob die Option gesetzt ist -i, mithilfe einer speziellen Minus-Variable - in bash, zum Beispiel:

$ echo $-

Wenn das Ausgabezeichen ivorhanden ist, ist die Shell interaktiv.

In einer Login-Shell?

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

Dann sucht es nacheinander nach einer dieser drei Dateien:

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

Wenn eine gefunden wird, wird sie ausgeführt und die anderen übersprungen.

In einer interaktiven Shell?

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

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

/etc/bash.bashrc
~/.bashrc

Keine Option?

Wenn Sie sich weder in einer Login- noch in einer interaktiven Shell befinden, ist Ihre Umgebung tatsächlich leer. Das kann für viel Verwirrung sorgen (siehe unten zu cron-Jobs).

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

Typische Schwierigkeiten und empirische Regeln

Cron-Jobs

In 95 % der Fälle hängt die Fehlersuche bei Bash-Skripten damit zusammen, dass der Cron-Job nicht wie erwartet funktioniert.

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

Hier Zwei Gründe:

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

Normalerweise bemerken oder kümmern Sie sich nicht darum, dass ein Shell-Skript nicht interaktiv ist, weil die Umgebung von der interaktiven Shell geerbt wird. Das bedeutet, dass alles PATH und alias so konfiguriert ist, wie Sie es erwarten.

Deshalb muss oft eine spezifische PATH Umgebung für den Cron-Job festgelegt werden, wie hier:

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

Skripte, die sich gegenseitig aufrufen

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

Geschieht normalerweise, wenn jemand versucht hat, einen Fehler zu beheben und es so aussieht, als ob alles funktioniert. Leider entstehen neue Probleme, wenn diese verschiedenen Arten von Sitzungen getrennt werden müssen.

Docker-Image in der Sandbox

Um mit dem Start der Shell zu experimentieren, habe ich ein Docker-Image erstellt, das zur Fehlersuche beim Start der Shell in einer sicheren Umgebung verwendet werden kann.

Start:

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

Die Dockerfile befindet sich hier.

Für einen erzwungenen Login und zur Simulation des Shell-Logins:

$ bash --login

Um die Umgebungsvariablen zu überprüfen BASH_ENV:

$ env | grep BASH_ENV

Zur Fehlersuche crontab wird alle Minute ein einfaches Skript ausgeführt (in /root/ascript):

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

Quelle: habr.com