Une introduction aux variables spéciales et d'environnement les plus utiles dans Bash

Apprenez-vous actuellement Bash ? Avez-vous vu des choses comme $0 et $EUID et je me demandais ce qu'ils voulaient dire ? Ou quelle est la différence entre $UID et $EUID? J'en parlerai et bien plus encore : ce qu'ils font et pourquoi ils sont importants.

Paramètres spéciaux

Les paramètres spéciaux sont des variables fournies par Bash à des fins spécifiques. Il y en a moins de 10, et les suivants me semblent les plus utiles.

Obtenez le chemin du script

Parfois, lorsque vous écrivez un script, vous souhaitez connaître son chemin. Par exemple, lors de la création d'un menu d'aide, il est d'usage d'inclure le nom du script en haut. Voici le menu d'aide de la commande ls :

ls --help

Vous pouvez accéder au chemin (relatif) en utilisant le $0 paramètre spécial. Il s'agit d'un standard POSIX, vous pouvez donc l'utiliser dans la plupart des shells :

echo "$0"

Ensuite, vous pouvez obtenir le nom du script en utilisant $(basename $0):

Cependant, parfois $0 n'est pas fiable ; par exemple, la source /path/to/script.sh renvoie « bash » et non le chemin du script. Au lieu de cela, utilisez le $BASH_SOURCE variable, qui fonctionne presque à l’identique, sauf sans surprises. Si vous utilisez uniquement Bash, c'est le meilleur choix, mais il n'est pas portable vers d'autres shells.

Déterminer l'état de sortie d'un processus

Chaque programme renvoie un nombre à la sortie. C'est ce qu'on appelle le code de sortie et il est utilisé pour prendre des décisions lorsqu'une commande renvoie une erreur. Par exemple, si vous essayez de ls un répertoire inexistant, il renvoie une valeur non nulle.

Un statut de sortie zéro signifie le succès ; une valeur différente de zéro indique un problème.

Lorsque vous rencontrez un problème, vous souhaiterez peut-être interrompre l'exécution et le $? un paramètre spécial fournit le code de sortie nécessaire :

ls /system32
echo $?

Il existe plusieurs façons de détecter et de gérer un code de sortie. La plus évidente est d'évaluer « $? » avec une instruction conditionnelle :

if (( $? -eq 0 )); then
   # If the script executed successfully.
fi

Le code de sortie signifie généralement quelque chose et est spécifique au programme, mais vous pouvez gérer des valeurs distinctes avec une instruction case :

case $? in
  0) echo "OK";;
  1) echo "Err";;
  *) echo "Unhandled error";;
esac

Une de mes approches préférées consiste à utiliser une instruction conditionnelle sans crochets :

if ls /system32; then
  # Upon zero exit code.
  echo "/system32 exists"
fi

Mais la solution la plus élégante consiste à utiliser des opérateurs logiques :

ls /system32 && echo "/system32 exist" # && executes on zero exit status.
ls /system32 || echo "/system32 does not exist" # || executes on non-zero exit status.

Arguments d'accès

Si vous écrivez un script Bash, vous devrez invariablement lui transmettre des valeurs, c'est-à-dire des arguments ou des paramètres de position. L'approche de Bash est un peu maladroite, mais elle fonctionne. Les exemples sont le moyen le plus simple de les comprendre :

foo() {
  echo "$1" # First argument.
  echo "$2" # Second argument.
}
foo "first" "second"

J'ai passé des arguments dans une fonction, mais ils fonctionnent exactement de la même manière au niveau supérieur de votre script. Par exemple:

#!/usr/bin/env bash
# This is the top-level of your script.
echo "The first argument: $1"
echo "The second argument: $2"

Vous pouvez ensuite transmettre des arguments dans votre script via la CLI : script.sh "first" "second".

Ensuite, le paramètre spécial « $@ » représente tous les arguments sous forme de tableau :

foo() {
  for arg in "$@"; do
    echo "$arg"
  done
}
foo "first" "second"

Le paramètre spécial « $* » est identique à « $@ », sauf qu'il met tous les arguments dans une seule chaîne (si « $* » a des guillemets doubles) :

at() {
  printf '@: (%s)n' "$@"
}

star() {
  printf '*: (%s)n' "$*"
}

at   "one two" "three"
star "one two" "three"

Vous pouvez voir que « $@ » imprime les deux arguments sur deux lignes, mais « $* » les imprime sur une seule ligne.

Pour obtenir le nombre d'arguments, vous pouvez utiliser la ${#@} ou ${#*} syntaxe:

foo() {
  echo ${#@}
  echo ${#*}
}
foo "one" "two"

Variables d'environnement

Les variables d'environnement sont des valeurs fournies aux programmes en cours d'exécution par le shell. Par exemple, $HOME fournit le chemin d'accès au répertoire personnel de l'utilisateur actuel.

Obtenir l'ID utilisateur

Parfois, j'ai besoin de connaître l'ID utilisateur actuel dans un script. Par exemple, récemment, j'interagissais avec un socket dans le /run/user/1000 annuaire. Le « 1000 » est l'ID utilisateur, et si nous voulons un script robuste, nous ne devons pas coder en dur cette valeur, car un autre utilisateur qui l'exécute peut avoir un ID utilisateur différent.

Pour résoudre ce problème, nous pouvons utiliser le $UID et $EUID variables. « $UID » affiche l'ID de l'utilisateur exécutant un binaire. « $EUID » (ID utilisateur effectif) est l'ID utilisateur du processus exécutant un binaire. Normalement, ceux-ci sont égaux, mais pour les binaires setuid, ils peuvent différer. Par exemple, lors de l'exécution de quelque chose avec sudo, ils varient à mesure que le fork progresse à travers différentes étapes.

ps --forest -eo cmd,euid,ruid | grep -C 1 '(s)udo'

J'ai « sudo sleep 600 » exécuté en arrière-plan et l'invite ci-dessus affiche les colonnes de commande, EUID (« 1 ») et UID (« 2 ») pour tout processus exécutant sudo. Vous pouvez voir que l'EUID devient immédiatement « 0 », mais l'UID ne change pas jusqu'au processus forké final (qui est « en veille » exécuté en tant que root).

Que pouvons-nous en retenir ? Eh bien, peu importe celui que vous utilisez. Certains disent d'utiliser « $EUID » pour vérifier si vous disposez des privilèges root, car ce sont les autorisations effectives. Cependant, vous pouvez voir sur l'image que le processus final de « veille » a à la fois l'UID et l'EUID définis sur « 0 » (racine), et que le processus shell est tous deux défini sur « 1000 » (utilisateur). Ceux-ci représentent l'une ou l'autre extrémité du processus de fork, l'endroit où vous avez lancé la requête sudo ainsi que le processus d'exécution final. Par conséquent, il n'y a aucune distinction utile entre eux quand cela compte, mais rappelez-vous qu'ils diffèrent pour les binaires setuid pendant le processus de fork.

Obtenez des chemins d'utilisateur courants

Dans presque tous les scripts que j'écris, j'accède au répertoire personnel. Moins fréquemment, j'ai besoin d'accéder à ~/.config ou ~/.local/share. L'accès à des emplacements typiques dans le système de fichiers est courant, mais les chemins de codage en dur comme celui-ci sont une mauvaise pratique car ils peuvent changer. L'approche recommandée consiste à utiliser la spécification d'annuaire XDG, qui est un ensemble de variables standard fournies par freedesktop.org.

env | grep XDG | sort -u

Toutes les variables ne sont pas définies et certaines ne sont pas des chemins.

Lorsque vous utilisez des variables XDG, veillez à toujours définir une valeur par défaut raisonnable :

export "${XDG_CACHE_HOME:=$HOME/.cache}"

Cela définira également la variable (si elle n'est pas définie) et la rendra disponible pour tous les binaires ou scripts que vous exécutez.

Les variables les plus courantes que j'utilise :

export "${XDG_CACHE_HOME:=$HOME/.cache}"       # Semi-temporary data.
export "${XDG_CONFIG_HOME:=$HOME/.config}"     # Configuration files.
export "${XDG_DATA_HOME:=$HOME/.local/share}"  # Downloaded data, etc.

Il y en a plusieurs autres et je vous encourage à les apprendre. Vous devriez utiliser ces emplacements au lieu de tout écrire dans /tmp ou un répertoire personnalisé dans ~/.

---

En plus de ces variables, de nombreuses variables d'environnement utiles sont disponibles via le shell. Les variables couvertes représentent celles que j'utilise le plus souvent. Je ne pourrais pas écrire de scripts Bash sans eux. À l’inverse, le codage en dur des valeurs entraînera éventuellement des ruptures. Lorsque vous disposez de centaines de scripts, de telles pannes deviennent un cauchemar de maintenance. Par conséquent, il est préférable de déduire autant que possible d’ailleurs, de préférence à partir de variables standard, et les variables présentées ici aujourd’hui conviennent parfaitement.

En conclusion, apprenez et utilisez autant de variables standard que possible.