Lancement de Bash en détail

Si vous avez trouvé cette page dans une recherche, vous essayez probablement de résoudre un problÚme lié au lancement de bash.

Peut-ĂȘtre que dans votre environnement, bash ne dĂ©finit pas la variable d'environnement et vous ne comprenez pas pourquoi. Il se peut que vous ayez ajoutĂ© quelque chose dans divers fichiers de dĂ©marrage de bash ou dans les profils, ou dans tous les fichiers au hasard, jusqu'Ă  ce que cela fonctionne.

Quoi qu'il en soit, le but de cette note est de présenter le processus de lancement de bash le plus simplement possible, afin que vous puissiez résoudre les problÚmes.

Diagramme

Ce schéma résume tous les processus lors du lancement de bash.

Lancement de Bash en détail

Examinons maintenant chaque partie en détail.

Shell de connexion ?

Tout d'abord, vous devez choisir si vous ĂȘtes dans un shell de connexion ou non.

Un shell de connexion est le premier shell que vous atteignez lorsque vous vous connectez pour une session interactive. Un shell de connexion ne nécessite pas de saisie de nom d'utilisateur et de mot de passe. Vous pouvez forcer le lancement d'un shell de connexion en ajoutant le drapeau --login lors de l'appel bash, par exemple :

bash --login

Le shell de connexion configure l'environnement de base lors du premier lancement du shell bash.

Interactif ?

Ensuite, vous devez déterminer si le shell est interactif ou non.

Vous pouvez vérifier cela par la présence de la variable PS1 (elle définit la fonction d'entrée des commandes) :

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

Ou voir si le paramÚtre -i, avec une variable spéciale démarquée - dans bash, par exemple :

$ echo $-

S'il y a un caractĂšre i, alors le shell est interactif.

Dans un shell de connexion ?

Si vous ĂȘtes dans un shell de connexion, alors bash recherche le fichier /etc/profile et le lance s'il existe.

Il recherche ensuite l'un de ces trois fichiers dans l'ordre suivant :

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

Lorsqu'il en trouve un, il le lance et passe les autres.

Dans un shell interactif ?

Si vous ĂȘtes dans un shell interactif sans connexion (non-login shell), on suppose que vous avez dĂ©jĂ  Ă©tĂ© dans un shell de connexion, que l'environnement est configurĂ© et sera hĂ©ritĂ©.

Dans ce cas, les deux fichiers suivants sont exécutés dans cet ordre, s'ils existent :

/etc/bash.bashrc
~/.bashrc

Aucune option ?

Si vous n'ĂȘtes dans aucun shell de connexion ni dans un shell interactif, alors votre environnement sera effectivement vide. Cela crĂ©e beaucoup de confusion (voir ci-dessous sur les tĂąches cron).

Dans ce cas, bash regarde la variable BASH_ENV de votre environnement et crée le fichier correspondant qui y est spécifié.

Difficultés typiques et rÚgles empiriques

TĂąches cron

Dans 95 % des cas, le débogage d'un lancement bash est lié au fait que la tùche cron ne fonctionne pas comme prévu.

Cette tùche maudite fonctionne correctement lorsque je l'exécute dans la ligne de commande, mais échoue lors de son lancement dans crontab.

Ici deux raisons:

  • Les tĂąches cron ne sont pas interactives.
  • Contrairement aux scripts dans la ligne de commande, les tĂąches cron ne hĂ©riteront pas de l'environnement shell.

En général, vous ne remarquez pas ou ne vous souciez pas du fait que le script shell n'est pas interactif, car l'environnement est hérité de l'interface interactive. Cela signifie que tout PATH et alias est configuré comme vous vous y attendez.

C'est pourquoi il est souvent nécessaire de définir un PATH pour la tùche cron, comme ici :

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

Scripts appelant d'autres scripts

Un autre problÚme courant survient lorsqu'un script est configuré par erreur pour appeler un autre script. Par exemple, /etc/profile accesse à ~\/bashrc.

Cela se produit généralement quand quelqu'un essaie de corriger une erreur et que tout semble fonctionner. Malheureusement, lorsque vous devez séparer ces différents types de sessions, de nouveaux problÚmes apparaissent.

Image Docker dans un bac Ă  sable

Pour expĂ©rimenter l'exĂ©cution de l'interface shell, j'ai créé une image Docker qui peut ĂȘtre utilisĂ©e pour dĂ©boguer le lancement de l'interface shell dans un environnement sĂ»r.

Lancement :

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

Le Dockerfile se trouve ici.

Pour forcer la connexion et simuler une interface shell de connexion :

$ bash --login

Pour vérifier l'ensemble des variables BASH_ENV:

$ env | grep BASH_ENV

Pour le débogage crontab chaque minute exécutera un simple script (dans /root/ascript):

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

Source : habr.com

Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS đŸ”„ Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster