Zagon Basha v podrobnostih

Če ste to stran našli preko iskanja, verjetno poskušate rešiti težavo z zagonoma bash.

Morda v vašem okolju bash ne nastavlja okoljske spremenljivke in ne veste, zakaj. Morda ste nekaj dodali v različne zagonske datoteke bash ali v profile, ali pa ste vanje nalagali vse mogoče, dokler ni delovalo.

V vsakem primeru je namen te opombe, da na kar se da enostaven način predstavi postopek zagona bash, da boste lahko obvladali težave.

Diagram

Ta diagram povzema vse procese pri zagonu bash.

Sedaj si podrobneje oglejmo vsak del.

Login Shell?

Najprej morate ugotoviti, ali ste v prijavni lupini (login shell) ali ne.

Prijavna lupina je prva lupina, v katero vstopite ob prijavi na interaktivno sejo. Prijavna lupina ne zahteva vnosa uporabniškega imena in gesla. Prijavo lupine lahko prisilite ob zagonu s parametrom --login pri klicu bash, na primer:

bash --login

Prijavna lupina nastavi osnovno okolje ob prvem zagonu lupine bash.

Interaktivna?

Nato ugotovite, ali je lupina interaktivna ali ne.

To lahko preverite s prisotnostjo spremenljivke PS1 (nastavi funkcijo vnosa ukazov):

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

Ali preverite, ali je nastavitev -i, s pomočjo posebne spremenljivke pomišljaja - v bash, na primer:

$ echo $-

Če je v izhodu znak i, je lupina interaktivna.

V prijavni lupini?

Če ste v prijavni lupini, bash išče datoteko /etc/profile in jo zažene, če obstaja.

Nato išče katero od teh treh datotek v naslednjem vrstnem redu:

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

Ko eno najde, jo zažene in preostale preskoči.

V interaktivni lupini?

Če ste v interaktivni lupini brez prijave (non-login shell), se predpostavlja, da ste že bili v prijavni lupini, okolje je nastavljeno in se bo podedovalo.

V tem primeru se po vrsti izvajata naslednji dve datoteki, če obstajata:

/etc/bash.bashrc
~/.bashrc

Nobena možnost?

Če niste v prijavni lupini ali v interaktivni lupini, bo vaše okolje resnično prazno. To povzroča veliko zmede (glejte spodaj o cron opravilih).

V tem primeru bash pregleda spremenljivko BASH_ENV vašega okolja in ustvari ustrezno datoteko, kot je navedeno.

Tipične težave in empirična pravila

Cron Jobs

In 95% of cases, debugging a Bash startup relates to the cron job not working as expected.

This cursed task works fine when I run it from the command line, but fails when running in crontab.

Tukaj two reasons:

• Cron jobs are not interactive.
• Unlike scripts in the command line, cron jobs do not inherit the shell environment.

Usually, you don’t notice or care that the shell script is not interactive, because the environment is inherited from the interactive shell. This means that everything PATH in alias is configured as you expect.

That’s why you often need to set a specific PATH for the cron job, like this:

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

Scripts calling each other

Another common issue is when scripts mistakenly set up to call each other. For example, /etc/profile calls ~/.bashrc.

This usually happens when someone tried to fix a bug and it seems to work. Unfortunately, when needing to separate these different types of sessions, new problems arise.

Docker Image in Sandbox

To experiment with running a shell, I created a Docker image that can be used for debugging shell startup in a safe environment.

Zagon:

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

The Dockerfile is located ovde.

For forced login and simulating a login shell:

$ bash --login

To check the set of variables BASH_ENV:

$ env | grep BASH_ENV

For debugging crontab every minute a simple script will run (in /root/ascript):

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

Izvor: habr.com