Kører Bash i detaljer

Hvis du fandt denne side i en søgning, forsøger du sandsynligvis at løse et eller andet problem med at køre bash.

Måske indstiller dit bash-miljø ikke en miljøvariabel, og du forstår ikke hvorfor. Du kan have sat noget fast i forskellige bash boot-filer eller profiler eller alle filer tilfældigt, indtil det virkede.

Under alle omstændigheder er pointen med denne note at udforme proceduren for at starte bash så enkelt som muligt, så du kan håndtere problemer.

Диаграмма

Dette flowchart opsummerer alle processerne, når du kører bash.

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

Login Shell?

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

Login-skallen er den første shell, du indtaster, når du logger ind til en interaktiv session. Login-skallen kræver ikke et brugernavn og adgangskode. Du kan tvinge login-skallen til at starte ved at tilføje et flag --login når der ringes op bash, for eksempel:

bash --login

Login-skallen sætter basismiljøet op, når du første gang starter bash-skallen.

Interaktiv?

Derefter bestemmer du, om skallen er interaktiv eller ej.

Dette kan kontrolleres ved tilstedeværelsen af ​​variablen PS1 (det installerer kommandoindtastningsfunktionen):

if [ "${PS1-}" ]; derefter ekko interaktiv ellers ekko ikke-interaktiv fi

Eller se om indstillingen er indstillet -i, ved hjælp af en speciel bindestregsvariabel - i bash, for eksempel:

$echo$-

Hvis der er et symbol i outputtet i, så er skallen interaktiv.

I login-skallen?

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

Søger derefter efter en af ​​disse tre filer i følgende rækkefølge:

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

Når den finder en, starter den den og springer de andre over.

I en interaktiv skal?

Hvis du er i en ikke-login shell, antages det, at du allerede har været i en login shell, miljøet er konfigureret og vil blive nedarvet.

I dette tilfælde udføres følgende to filer i rækkefølge, hvis de findes:

/etc/bash.bashrc ~/.bashrc

Ingen mulighed?

Hvis du ikke er i hverken en login-shell eller en interaktiv shell, så vil dit miljø faktisk være tomt. Dette forårsager en del forvirring (se nedenfor om cron-job).

I dette tilfælde ser bash på variablen BASH_ENV dit miljø og opretter den tilsvarende fil, der er angivet der.

Almindelige vanskeligheder og tommelfingerregler

cron job

95 % af tiden, jeg fejlretter bash-startup, er det fordi cron-jobbet ikke kører som forventet.

Denne forbandede opgave fungerer fint når jeg kører det på kommandolinjen, men fejler når jeg kører det i crontab.

Her to grunde:

• Cron-job er ikke interaktive.
• I modsætning til kommandolinjescripts, arver cron-job ikke shell-miljøet.

Typisk vil du ikke bemærke eller bekymre dig om, at et shell-script ikke er interaktivt, fordi miljøet arver fra den interaktive shell. Det betyder, at alt PATH и alias konfigureret som du ville forvente.

Derfor er det ofte nødvendigt at indstille en specifik PATH til en cron opgave som her:

* * * * * PATH=${PATH}:/sti/til/mit/program/mappe mit program

Scripts kalder hinanden

Et andet almindeligt problem er, når scripts fejlagtigt er konfigureret til at kalde hinanden. For eksempel, /etc/profile appellerer til ~/.bashrc.

Dette sker normalt, når nogen forsøgte at rette en fejl, og alt så ud til at virke. Desværre, når du skal adskille disse forskellige typer sessioner, opstår der nye problemer.

Sandboxed Docker-billede

For at eksperimentere med at køre en shell, oprettede jeg et Docker-billede, der kan bruges til at fejlsøge at køre en shell i et sikkert miljø.

Lancering:

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

Dockerfile er placeret her.

For at tvinge login og simulere en login-shell:

$ bash --login

For at teste et sæt variable BASH_ENV:

$ env | grep BASH_ENV

Til fejlretning crontab et simpelt script vil blive udført hvert minut (i /root/ascript):

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

Kilde: www.habr.com