103.1 Leçon 2

Comment identifier les valeurs courantes de chacune de nos variables d’environnement ? Une façon de le faire est d’utiliser la commande env :

Vous obtiendrez beaucoup de résultats, bien plus que ce qui est inclus dans l’extrait ci-dessus. Mais pour l’instant, notez l’entrée PATH, qui contient les répertoires où votre shell (et d’autres programmes) vont chercher d’autres programmes sans avoir à spécifier le chemin complet. Avec cette configuration, vous pouvez exécuter un programme binaire qui se trouve, disons, dans /usr/local/bin depuis votre répertoire personnel et il fonctionnera comme si le fichier était local.

Changeons de sujet un instant. La commande echo affiche à l’écran tout ce que vous lui fournissez en argument. Eh bien, il y aura bien des fois où faire répéter littéralement quelque chose à echo nous sera très utile.

Mais il y a autre chose que vous pouvez faire avec echo. Lorsque vous lui fournissez le nom d’une variable d’environnement — et que vous lui indiquez qu’il s’agit d’une variable en préfixant le nom de la variable par un $ — alors, au lieu de simplement afficher le nom de la variable, l’interpréteur de commandes la développera en vous donnant sa valeur. Vous ne savez pas si votre répertoire préféré est actuellement dans le chemin ? Vous pouvez le vérifier rapidement en passant par echo :

Vous pouvez ajouter vos propres variables personnalisées à votre environnement. La méthode la plus simple consiste à utiliser le caractère =. La chaîne de caractères à gauche sera le nom de votre nouvelle variable et la chaîne de caractères à droite sera sa valeur. Vous pouvez dorénavant passer le nom de la variable à echo pour confirmer que ça a marché :

Mais est-ce que ça a vraiment marché ? Tapez bash dans le terminal pour lancer un nouveau shell. Ce nouveau shell ressemble exactement à celui que vous venez d’utiliser, mais il est en fait un enfant du shell original (que nous appelons le parent). Maintenant, à l’intérieur de ce nouveau shell enfant, essayez de faire fonctionner echo comme avant. Rien. Que se passe-t-il ?

Une variable que vous créez de la façon que nous venons de décrire ne sera disponible que localement, dans la session actuelle du shell. Si vous lancez un nouveau shell — ou si vous fermez la session en utilisant exit — la variable ne vous suivra pas. En tapant exit ici, vous retrouvez votre shell parent d’origine qui, pour l’instant, est l’endroit où nous voulons être. Vous pouvez relancer echo $myvar si vous voulez, juste pour vérifier que la variable est toujours disponible. Maintenant, tapez export myvar pour transmettre la variable à tous les shells enfants que vous pourrez ouvrir par la suite. Essayez : tapez bash pour lancer un nouveau shell et ensuite echo :

Tout cela peut sembler un peu bête lorsque l’on crée des shells sans objectif valable. Mais comprendre comment les variables de l’interpréteur de commandes se propagent dans votre système deviendra très important lorsque vous commencerez à écrire des scripts concrets.

Vous voulez savoir comment faire le ménage dans toutes ces variables éphémères que vous avez créées ? Une solution consiste tout simplement à fermer votre shell parent - ou à redémarrer votre machine. Mais il y a plus simple. Comme unset, par exemple. Taper unset (sans le $) va détruire la variable. echo nous le prouvera.

S’il y a une commande unset, il y a fort à parier qu’il existe une commande set qui va avec. Exécuter set tout seul affichera beaucoup de choses, et ce ne sera pas très différent de ce que env nous a donné. Regardez la première ligne du résultat lorsque vous filtrez avec le terme PATH :

Quelle est la différence entre set et env ? En ce qui nous concerne, l’essentiel est que set affiche toutes les variables et toutes les fonctions. Prenons un exemple. Nous allons créer une nouvelle variable appelée mynewvar et confirmer qu’elle est bien là :

Maintenant, lancer env en utilisant grep pour filtrer la chaîne mynewvar n’affichera rien. Mais en exécutant set de la même manière, nous verrons notre variable locale.

Le moment est venu de vous présenter le problème des caractères spéciaux. En temps normal, les caractères alphanumériques (a-z et 0-9) seront lus littéralement par Bash. Si vous essayez de créer un nouveau fichier appelé myfile, il vous suffit de taper touch suivi de myfile et Bash saura quoi en faire. Mais si vous voulez inclure un caractère spécial dans votre nom de fichier, ça se complique un peu.

Pour illustrer cela, nous allons taper touch et enchaîner avec le nom : my big file. Le problème, c’est qu’il y a deux espaces entre les mots que Bash va interpréter. Même si, techniquement, un espace n’est pas un "caractère", il en est un dans le sens où Bash ne le lira pas littéralement. Si vous affichez le contenu de votre répertoire actuel, au lieu d’un fichier appelé my big file, vous verrez trois fichiers nommés respectivement my, big et file. En effet, Bash considère que vous souhaitez créer une série de fichiers dont vous fournissez les noms dans une liste :

Les espaces seront interprétés de la même manière si vous supprimez (rm) les trois fichiers en une seule commande :

Maintenant, essayons de procéder de la bonne manière. Tapez touch et les trois parties de votre nom de fichier, mais cette fois-ci, mettez le nom entre guillemets. Cette fois-ci ça a marché. Lorsque vous affichez le contenu du répertoire, vous voyez un seul fichier avec le nom approprié.

Il existe d’autres façons d’obtenir le même résultat. Les guillemets simples, par exemple, fonctionnent tout aussi bien que les guillemets doubles. (Notez que les guillemets simples préservent la valeur littérale de tous les caractères, tandis que les guillemets doubles préservent tous les caractères sauf $, `, \ et, dans certains cas, !).

En faisant précéder chaque caractère spécial d’une barre oblique inversée, on "échappe" à la spécificité du caractère et Bash le lira littéralement.