Kjører Bash i detalj

Hvis du fant denne siden i et søk, prøver du sannsynligvis å løse et problem med å kjøre bash.

Kanskje bash-miljøet ditt ikke angir en miljøvariabel, og du forstår ikke hvorfor. Du kan ha stukket noe i forskjellige bash-oppstartsfiler eller -profiler eller alle filer tilfeldig til det fungerte.

Uansett, poenget med dette notatet er å legge ut prosedyren for å starte bash så enkelt som mulig, slik at du kan håndtere problemer.

Diagram

Dette flytskjemaet oppsummerer alle prosessene når du kjører bash.

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

Logg inn Shell?

Først må du velge om du er i påloggingsskallet eller ikke.

Innloggingsskallet er det første skallet du går inn i når du logger på for en interaktiv økt. Innloggingsskallet krever ikke brukernavn og passord. Du kan tvinge innloggingsskallet til å starte ved å legge til et flagg --login når du ringer bash, for eksempel:

bash --logg inn

Innloggingsskallet setter opp basemiljøet når du først starter bash-skallet.

Interaktiv?

Deretter bestemmer du om skallet er interaktivt eller ikke.

Dette kan kontrolleres ved tilstedeværelsen av variabelen PS1 (den installerer kommandoinndatafunksjonen):

if [ "${PS1-}" ]; deretter ekko interaktivt annet ekko ikke-interaktivt fi

Eller se om alternativet er satt -i, ved å bruke en spesiell bindestrekvariabel - i bash, for eksempel:

$echo$-

Hvis det er et symbol i utgangen i, da er skallet interaktivt.

I påloggingsskallet?

Hvis du er i et påloggingsskall, ser bash etter filen /etc/profile og kjører hvis den finnes.

Søker deretter etter noen av disse tre filene i følgende rekkefølge:

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

Når den finner en, starter den den og hopper over de andre.

I et interaktivt skall?

Hvis du er i et ikke-påloggingsskall, antas det at du allerede har vært i et påloggingsskall, miljøet er konfigurert og vil bli arvet.

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

/etc/bash.bashrc ~/.bashrc

Ingen mulighet?

Hvis du ikke er i verken et påloggingsskall eller et interaktivt skall, vil miljøet ditt virkelig være tomt. Dette skaper mye forvirring (se nedenfor om cron-jobber).

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

Vanlige vanskeligheter og tommelfingerregler

cron jobber

95 % av tiden jeg feilsøker bash-oppstart er det fordi cron-jobben ikke kjører som forventet.

Denne jævla oppgaven fungerer fint når jeg kjører det på kommandolinjen, men mislykkes når jeg kjører det i crontab.

Her to grunner:

• Cron-jobber er ikke interaktive.
• I motsetning til kommandolinjeskript, arver ikke cron-jobber skallmiljøet.

Vanligvis vil du ikke legge merke til eller bry deg om at et skallskript ikke er interaktivt fordi miljøet arver fra det interaktive skallet. Dette betyr at alt PATH и alias konfigurert som du forventer.

Dette er grunnen til at det ofte er nødvendig å angi en spesifikk PATH for en cron-oppgave som her:

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

Skript som kaller hverandre

Et annet vanlig problem er når skript feilaktig er konfigurert til å ringe hverandre. For eksempel, /etc/profile appellerer til ~/.bashrc.

Dette skjer vanligvis når noen prøvde å fikse en feil og alt så ut til å fungere. Dessverre, når du trenger å skille disse ulike typene økter, oppstår nye problemer.

Sandboxed Docker-bilde

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

Lansering:

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

Dockerfile er lokalisert her.

For å tvinge pålogging og simulere et påloggingsskall:

$ bash --login

For å teste et sett med variabler BASH_ENV:

$ env | grep BASH_ENV

For feilsøking crontab et enkelt skript vil bli utført hvert minutt (i /root/ascript):

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

Kilde: www.habr.com