Kjøring av Bash i detalj

Dersom du har funnet denne siden gjennom søk, prøver du sannsynligvis å løse et problem med å starte bash.

Kanskje miljøet ditt ikke setter miljøvariabelen i bash, og du forstår ikke hvorfor. Kanskje har du puttet noe i diverse oppstartsfiler for bash eller i profiler, eller i alle filer på slump, inntil det fungerte.

Uansett, meningen med denne notisen er å så enkelt som mulig forklare prosedyren for å starte bash, slik at du kan håndtere problemene.

Flytskjema

Dette flytskjemaet oppsummerer alle prosessene ved oppstart av bash.

La oss nå se nærmere på hver del.

Login Shell?

Først må du vurdere om du er i en login shell eller ikke.

En login shell er den første shellen du kommer inn i når du logger inn i systemet for en interaktiv økt. Login shell krever ikke at du skriver inn brukernavn og passord. Du kan tvinge oppstart av login shell ved å legge til flagget --login ved anropet bash, for eksempel:

bash --login

Login shell setter opp ditt grunnleggende miljø ved første oppstart av bash-shell.

Interaktiv?

Deretter avgjør du om shellen er interaktiv eller ikke.

Dette kan sjekkes ved å se om variabelen PS1 er satt (den angir kommandoinngangsfunksjonen):

if [ "${PS1-}" ]; then
  echo interactive
else
  echo non-interactive
fi

Eller ved å se om parameteren -i, kan sjekkes med spesialvariabelen for bindestrek - i bash, for eksempel:

$ echo $-

Hvis resultatet inneholder symbolet i, da er shellen interaktiv.

I login shell?

Hvis du er i en login shell, vil bash lete etter filen /etc/profile og kjøre den hvis den finnes.

Den leter deretter etter noen av disse tre filene i følgende rekkefølge:

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

Når den finner en, kjører den denne og hopper over de andre.

I interaktiv shell?

Hvis du er i en interaktiv shell uten login (non-login shell), antas det at du allerede har vært i en login shell, miljøet er satt opp og vil bli arvet.

I dette tilfellet kjøres de følgende to filene i rekkefølge hvis de eksisterer:

/etc/bash.bashrc
~/.bashrc

Ingen alternativer?

Hvis du ikke er i verken en login shell eller en interaktiv shell, vil miljøet ditt faktisk være tomt. Dette fører til mye forvirring (se nedenfor om cron-jobber).

I dette tilfellet ser bash på variabelen BASH_ENV i miljøet ditt og oppretter den tilsvarende filen som er angitt der.

Typiske vansker og empiriske regler

Cron-jobber

I 95% av tilfellene er feilsøking av bash-kjøring relatert til at cron-jobben ikke oppfører seg som forventet.

Denne forbannede oppgaven kjører fint når jeg starter den i kommandolinjen, men feiler når den kjøres i crontab.

Her to grunner:

• Cron-jobber er ikke interaktive.
• I motsetning til skripter i kommandolinjen, arver ikke cron-jobber miljøet fra skall.

Vanligvis legger du ikke merke til eller bryr deg om at skallskriptet ikke er interaktivt, fordi miljøet arves fra den interaktive skallet. Dette betyr at alt PATH og alias er satt opp slik du forventer.

Dette er grunnen til at det ofte er nødvendig å sette spesifikke PATH for cron-jobben, som her:

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

Skripter som kaller på hverandre

En annen vanlig problemstilling er når skripter ved en feil er konfigurert til å kalle hverandre. For eksempel, /etc/profile tilgår ~\/bashrc.

Dette skjer vanligvis når noen har prøvd å fikse en feil, og så ser det ut til å fungere. Dessverre, når forskjellige sesjoner må skilles, oppstår nye problemer.

Docker-image i sandkasse

For å eksperimentere med å kjøre skall, opprettet jeg et Docker-image som kan brukes til å feilsøke skallstart i et trygt miljø.

docker-compose -f sonar.yml up

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

Dockerfile ligger her.

For å tvinge innlogging og simulere innloggingsskall:

$ bash --login

For å sjekke settet med variabler BASH_ENV:

$ env | grep BASH_ENV

For feilsøking crontab hver minutt vil et enkelt skript kjøres (i /root/ascript):

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

Kilde: habr.com