Avvio di Bash in dettaglio

Se hai trovato questa pagina tramite una ricerca, stai sicuramente cercando di risolvere un problema con l'avvio di bash.

È possibile che nel tuo ambiente bash non venga impostata la variabile d'ambiente e non capisci perché. Potresti aver inserito qualcosa nei vari file di avvio di bash o nei profili, o in tutti i file a caso, finché non ha funzionato.

In ogni caso, il significato di questo appunto è esporre la procedura di avvio di bash nel modo più semplice possibile, in modo da poter affrontare i problemi.

Diagramma

Questo diagramma riassume tutti i processi coinvolti nell'avvio di bash.

Esaminiamo ora più nel dettaglio ogni parte.

Login Shell?

Per prima cosa, devi determinare se sei in una shell di login o meno.

La shell di login è la prima shell in cui entri quando accedi al sistema per una sessione interattiva. La shell di login non richiede l'immissione di nome utente e password. Puoi forzare l'avvio della shell di login aggiungendo il flag --login quando viene chiamato bash, ad esempio:

bash --login

La shell di login configura l'ambiente di base al primo avvio della shell bash.

Interattiva?

Dopo, devi determinare se la shell è interattiva o meno.

Puoi controllarlo dalla presenza della variabile PS1 (imposta la funzione di input dei comandi):

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

Oppure controlla se è impostato il parametro -i, usando una variabile speciale con il trattino - in bash, ad esempio:

$ echo $-

Se nel risultato appare il carattere i, allora la shell è interattiva.

Sei nella shell di login?

Se ti trovi in una shell di login, bash cerca il file /etc/profile e lo esegue, se esiste.

Quindi cerca uno di questi tre file in questo ordine:

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

Quando ne trova uno, lo esegue e salta gli altri.

Sei in una shell interattiva?

Se ti trovi in una shell interattiva senza login (non-login shell), si presume che tu sia già stato in una shell di login, che l'ambiente sia stato configurato e sarà ereditato.

In questo caso vengono eseguiti in ordine i seguenti due file, se esistono:

/etc/bash.bashrc
~/.bashrc

Nessuna opzione?

Se non sei né in una shell di login né in una shell interattiva, allora il tuo ambiente sarà davvero vuoto. Questo crea molta confusione (vedi sotto riguardo ai compiti cron).

In questo caso bash guarda alla variabile BASH_ENV del tuo ambiente e crea il file corrispondente specificato lì.

Difficoltà comuni e regole empiriche

Compiti cron

Nel 95% dei casi, il debug di uno script bash è legato al fatto che il compito cron non funziona come previsto.

Questo maledetto compito funziona correttamente quando lo eseguo nella riga di comando, ma fallisce quando viene eseguito in crontab.

Qui due motivi:

• I compiti cron non sono interattivi.
• Diversamente dagli script nella riga di comando, i compiti cron non ereditano l'ambiente della shell.

Di solito non te ne accorgi o non ti preoccupi del fatto che uno script di shell non sia interattivo, perché l'ambiente è ereditato dalla shell interattiva. Questo significa che tutto PATH e alias è configurato come ti aspetti.

Ecco perché spesso è necessario impostare esplicitamente un PATH per il compito cron, come qui:

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

Script che si chiamano a vicenda

Un altro problema comune è quando gli script sono erroneamente configurati per chiamarsi reciprocamente. Ad esempio, /etc/profile si riferisce a ~/.bashrc.

Di solito succede quando qualcuno ha cercato di correggere un errore e sembrava funzionare. Sfortunatamente, quando è necessario separare questi diversi tipi di sessioni, sorgono nuovi problemi.

Immagine Docker nel sandbox

Per sperimentare con l'avvio della shell, ho creato un'immagine Docker che può essere utilizzata per il debugging dell'avvio della shell in un ambiente sicuro.

Avvio:

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

Il Dockerfile si trova qui.

Per il login forzato e l'emulazione della shell di accesso:

$ bash --login

Per verificare il set di variabili BASH_ENV:

$ env | grep BASH_ENV

Per il debug crontab un semplice script verrà eseguito ogni minuto (nel /root/ascript):

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

Fonte: habr.com