Kørsel af Bash i detaljer

Hvis du har fundet denne side via en søgning, forsøger du sikkert at løse et problem med at starte bash.

Måske er miljøvariablen ikke sat i dit bash-miljø, og du forstår ikke hvorfor. Måske har du smidt noget ind i forskellige startfiler for bash eller i profiler, eller i alle filer tilfældigt, indtil det virkede.

Under alle omstændigheder er meningen med denne note at fremlægge proceduren for at starte bash så enkelt som muligt, så du kan håndtere problemerne.

Diagram

Dette flowchart opsummerer alle processer ved opstart af bash.

Lad os nu se nærmere på hver del.

Login Shell?

Først skal du vælge, om du er i en login shell eller ej.

En login shell er den første shell, du kommer ind i, når du logger ind i et interaktivt session. En login shell kræver ikke indtastning af brugernavn og password. Du kan tvinge opstart af en login shell ved at tilføje flag --login ved kald af bash, for eksempel:

bash --login

Login shell konfigurerer miljøet ved den første opstart af bash-shellet.

Interaktiv?

Derefter bestemmer du, om shell’en er interaktiv eller ej.

Dette kan kontrolleres ved at se efter miljøvariablen PS1 (den sætter funktionen til kommandoprompt):

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

Eller tjekke om parameteren -ier sat, ved hjælp af den særlige minusvariabel - i bash, for eksempel:

$ echo $-

Hvis der er et tegn i, så er shell’en interaktiv.

I login shell?

Hvis du er i en login shell, så leder bash efter filen /etc/profile og kører den, hvis den eksisterer.

Derefter leder den efter en af disse tre filer i den rækkefølge:

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

Når den finder én, kører den den og springer de andre over.

I den interaktive shell?

Hvis du er i en interaktiv shell uden login (non-login shell), antages det, at du allerede har været i en login shell, og miljøet er sat op og vil blive arvet.

I det tilfælde kører de følgende to filer i rækkefølge, hvis de eksisterer:

/etc/bash.bashrc
~/.bashrc

Ingen af delene?

Hvis du ikke er i hverken en login shell eller en interaktiv shell, så vil dit miljø faktisk være tomt. Dette kan forvirre meget (se nedenfor om cron jobs).

I dette tilfælde ser bash på miljøvariablen BASH_ENV og skaber den tilsvarende fil, der er angivet dér.

Typiske udfordringer og tommelfingerregler

Cron-jobs

I 95% af tilfældene er fejlsøgning af bash-start relateret til, at cron-jobbet ikke fungerer som forventet.

Det forbandede job fungerer fint, når jeg kører det i kommandolinjen, men fejler når det kører i crontab.

Her to årsager:

• Cron-jobs er ikke interaktive.
• I modsætning til scripts i kommandolinjen arver cron-jobs ikke shell-miljøet.

Normalt bemærker du ikke eller bekymrer dig om, at shell-scriptet ikke er interaktivt, fordi miljøet arves fra den interaktive shell. Det betyder, at alt PATH og alias er sat op som forventet.

Derfor skal du ofte indstille specifikke PATH for cron-jobbet, som her:

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

Scripts der kalder hinanden

En anden almindelig fejl er, når scripts fejlagtigt er konfigureret til at kalde hinanden. For eksempel, /etc/profile tilgår ~\/ .bashrc.

Normalt sker dette, når nogen har prøvet at rette en fejl, og det tilsyneladende fungerer. Desværre skaber det nye problemer, når forskellige sessionstyper skal adskilles.

Docker-billedet i sandkassen

For at eksperimentere med at starte shellen, har jeg oprettet et Docker-billede, der kan bruges til at debugge shell-start i et sikkert miljø.

Aktivering:

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

Dockerfilen findes her.

Til tvungen login og simulering af login-shell:

$ bash --login

For at kontrollere variabelsæt BASH_ENV:

$ env | grep BASH_ENV

Til fejlsøgning crontab vil et simpelt script køre hvert minut (i /root/ascript):

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

Kilde: habr.com