Uruchamianie Bash w szczegółach

Jeśli znalazłeś tę stronę w wyszukiwarce, to na pewno próbujesz rozwiązać jakiś problem z uruchomieniem basha.

Możliwe, że w Twoim środowisku bash nie ustawia zmiennej środowiskowej i nie rozumiesz, dlaczego. Może wrzuciłeś coś do różnych plików startowych basha lub profili, lub do wszystkich plików na ślepo, aż w końcu zaczęło działać.

W każdym razie celem tej notatki jest jak najprościej przedstawić procedurę uruchamiania basha, abyś mógł poradzić sobie z problemami.

Diagram

Ta blokada podsumowuje wszystkie procesy przy uruchamianiu basha.

Uruchamianie Bash w szczegółach

Teraz przyjrzyjmy się szczegółowo każdej części.

Shell logowania?

Najpierw musisz określić, czy jesteś w powłoce logowania (login shell), czy nie.

Powłoka logowania to pierwsza powłoka, do której trafiasz po zalogowaniu się do systemu na interaktywną sesję. Powłoka logowania nie wymaga podawania nazwy użytkownika i hasła. Możesz wymusić uruchomienie powłoki logowania, dodając flagę --login przy wywołaniu bash, na przykład:

bash --login

Powłoka logowania ustawia podstawowe środowisko przy pierwszym uruchomieniu powłoki basha.

Interaktywna?

Następnie określasz, czy powłoka jest interaktywna, czy nie.

Można to sprawdzić, szukając zmiennej PS1 (ustawia funkcję wprowadzania komend):

if [ "${PS1-}" ]; then
  echo interaktywne
else
  echo nie-interaktywne
fi

Lub sprawdzając, czy ustawiony jest parametr -i, za pomocą specjalnej zmiennej z myślnikiem - w bashu, na przykład:

$ echo $-

Jeśli w wyniku znajduje się symbol i, to powłoka jest interaktywna.

W powłoce logowania?

Jeśli jesteś w powłoce logowania, to bash szuka pliku /etc/profile i uruchamia go, jeśli istnieje.

Następnie szuka jednego z tych trzech plików w następującej kolejności:

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

Gdy znalazł jeden, uruchamia go i pomija inne.

W powłoce interaktywnej?

Jeśli jesteś w interaktywnej powłoce bez logowania (non-login shell), zakłada się, że już byłeś w powłoce logowania, środowisko jest skonfigurowane i będzie dziedziczone.

W takim przypadku wykonywane są po kolei dwie poniższe pliki, jeśli istnieją:

/etc/bash.bashrc
~/.bashrc

Żaden z wariantów?

Jeśli nie jesteś ani w powłoce logowania, ani w interaktywnej powłoce, Twoje środowisko będzie naprawdę puste. To powoduje dużą dezorientację (zobacz poniżej o zadaniach cron).

W takim przypadku bash patrzy na zmienną BASH_ENV Twojego środowiska i tworzy odpowiedni plik, który tam wskazano.

Typowe trudności i zasady empiryczne

Zadania cron

W 95% przypadków debugowanie uruchamiania bash jest związane z tym, że zadanie cron działa nie tak, jak oczekiwano.

To przeklęte zadanie działa prawidłowo, gdy uruchamiam je w linii poleceń, ale nie udaje się go uruchomić w crontabie.

Tutaj dwie przyczyny:

  • Zadania cron nie są interaktywne.
  • W przeciwieństwie do skryptów w linii poleceń, zadania cron nie dziedziczą środowiska powłoki.

Zwykle nie zauważasz ani nie dbasz o to, że skrypt powłoki nie jest interaktywny, ponieważ środowisko dziedziczy się z interaktywnej powłoki. Oznacza to, że wszystkie ŚCIEŻKA i alias są skonfigurowane tak, jak oczekujesz.

To dlatego często trzeba ustawić konkretne ŚCIEŻKA dla zadania cron, jak tutaj:

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

Skrypty wywołujące się nawzajem

Jeszcze jeden powszechny problem, gdy skrypty przypadkowo skonfigurowano do wywoływania się nawzajem. Na przykład, /etc/profile odnosi się do ~\/ .bashrc.

To zwykle się zdarza, gdy ktoś próbował naprawić jakiś błąd i wydawało się, że wszystko działa. Niestety, gdy trzeba oddzielić te różne typy sesji, pojawiają się nowe problemy.

Obraz Dockera w piaskownicy

Aby poeksperymentować z uruchamianiem powłoki, stworzyłem obraz Dockera, który można wykorzystać do debugowania uruchamiania powłoki w bezpiecznym środowisku.

Uruchomienie:

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

Dockerfile znajduje się tutaj.

Aby wymusić logowanie i imituje powłokę logowania:

$ bash --login

Aby sprawdzić zbiór zmiennych BASH_ENV:

$ env | grep BASH_ENV

Aby debugować crontab co minutę zostanie uruchomiony prosty skrypt (w /root/ascript):

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

Źródło: habr.com

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster