Discussion :

[Philippe Dpt35]

Bonjour,

j'ai quelques difficultés à bien cerner la portée des variables d'environnement crées dans ~/.bashrc et ~/.bash_profile

Si j'inscris

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

variable="test"

dans ces fichiers, cette variable est bien lisible par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printenv variable

ou bien par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo "$variable"

dans n'importe quelle console qui sera ouverte.

Mais cette variable est vide si je l'appelle dans un script :
test.sh

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#!/bin/bash
echo "$variable"

Là l'exécution de test.sh ne me renvoie aucune valeur.

Qui peut me fournir une explication ?
Comment est-il possible de définir une variable d'environnement lisible dans tous les cas au niveau de la session ?

[Flodelarab]

Bonjour

Ce que tu cherches ne serait-il pas le fait qu'un enfant ignore tout de son parent ? Il faut exporter la variable pour qu'elle soit accessible dans un sous-shell.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export variable="test"

ou (si elle a déjà été définie)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export variable

[disedorgue]

En complément de la réponse de FLodelarab, un bash non interactif (qui execute juste un script shell) ne charge pas de fichier de config, il hérite juste de l'environnement parent.

[chrtophe]

Pour utiliser un fichier de conf avec un bash non interactif, on peut pas utiliser la variable d'environnement BASH_ENV ?

[Philippe Dpt35]

A partir de vos indications et d'autres recherches sur le Net, j'ai fait une petite synthèse qui pourra servir à d'autres.

Les fichiers gérant les variables d'environnement au niveau de la session :
.bashrc
.bash_profile
.profile

Pour visualiser les variables d'environnement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printenv

Pour examiner une valeur particulière :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printenv variable

Distinguer shell interactifs et shell non-interactifs. Un script est lancé dans un shell non-interactif

Les variables d'environnement ont une portée locale. Ainsi une variable déclarée dans un shell ne sera valide que pour ce shell et ses enfants (mais pas pour un sous-shell non interactif, comme celui lancé par un script notamment).
Ex:
si je définis la variable

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
variable="test"
echo "$variable"

ne renverra test que dans le shell courant
Si l'on crée le script test.sh avec pour contenu

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#!/bin/bash
echo "$variable"

L'exécution du script renverra une valeur vide puisque le script s'est exécuté dans un shell non-interactif.
En revanche, si je définis la variable

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LANG=us_US.UTF-8

lorsque je lance un éditeur de texte depuis ce terminal, il se lancera en langue anglaise. Il y a bien héritage.

Pour qu'une variable ait une porté générale, il faut l'exporter par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export variable="test"

N'importe quel shell (sauf un shell non-interactif, comme après lancement d'un script) aura accès à la valeur.

Cette valeur sera perdue après la fermeture de la session.

Pour disposer de cette valeur de manière permanente au niveau de la session, il faut l'inscrire dans un des fichiers d'environnement .bashrc, .bash_profile, .profile

Usage de ces différents fichiers (repris depuis doc.ubuntu-fr.org)

- ~/.profile - C'est probablement le meilleur endroit pour placer une définition de variable d'environnement. En effet, il est exécuté automatiquement par le gestionnaire de connexion lors du démarrage d'une session graphique, mais aussi lors du démarrage d'une session en mode console texte.
~/.bash_profile ou ~/.bash_login - Si l'un de ces fichiers existe, il sera exécuté par Bash préférentiellement à ~/.profile lors d'une connexion sur une console. (Bash utilisera ~/.bash_profile de préférence à ~/.bash_login). Cependant, ces fichiers n'auront par défaut aucune influence sur une session en mode graphique.
- ~/.bashrc - Du fait de la manière dont Ubuntu configure par défaut les divers fichiers de scripts, c'est sans doute l'endroit le plus facile pour définir des variables. La configuration par défaut garantit a peu près que ce fichier sera exécuté à chaque invocation de *bash* ainsi que lors de la connexion à l'environnement graphique. Cependant du point de vue des performances, ce n'est pas l'idéal car les variables seront inutilement redéfinies à chaque fois. (NdT : à chaque fois que vous ouvrez un terminal par exemple?)

Comment définir des variables qui seront accessibles depuis des shell non-interactifs (donc des scripts) ?
On peut créer un script contenant les variables et leurs valeurs par exemple :
.variables.sh

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

variable="test"

Dans les scripts, on pourra accéder à ces valeurs en inscrivant dans le script la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

source $HOME/.variables.sh

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

. $HOME/.variables.sh

Il est possible d'inscrire le chemin vers ce fichier dans la variable BASH_ENV, par exemple dans .profile

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export BASH_ENV=$HOME/.variables.sh

Dès lors je peux y faire appel dans les scripts par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

. $BASH_ENV"

Merci de corriger les éventuelles erreurs et imprécisions.
.

[Flodelarab]

Les variables d'environnement ont une portée locale. Ainsi une variable déclarée dans un shell ne sera valide que pour ce shell et ses enfants (mais pas pour un sous-shell non interactif, comme celui lancé par un script notamment).

J'ai beaucoup de mal avec ce passage.

• Déjà je n'aurais pas mis "et ses enfants". Pas ses enfants, puisqu'il faut l'exporter.
• Ensuite, le paradoxe entre "portée locale" et "variable d'environnement" étonne. Tu montres toi-même que LANG n'est pas si locale que ça puisque la valeur est la même dans le script enfant.
• Enfin, la remarque sur l'interactivité n'a rien à voir avec la portée. Dans ton premier message, tu mettais en opposition l'indisponibilité d'une valeur dans un script alors que tu l'avais défini dans .bashrc.Ce que t'as précisé disedorgue, c'est que le .bashrc n'est exécuté que quand tu lances la console. Ainsi la valeur est disponible dans la console. Mais pas ses enfants. Or un script est un enfant. Donc, indisponibilité dans le script. À moins de transmettre ou exporter.

[Philippe Dpt35]

J'ai beaucoup de mal avec ce passage.

• Déjà je n'aurais pas mis "et ses enfants". Pas ses enfants, puisqu'il faut l'exporter.
• Ensuite, le paradoxe entre "portée locale" et "variable d'environnement" étonne. Tu montres toi-même que LANG n'est pas si locale que ça puisque la valeur est la même dans le script enfant.

Sur ce point, je ne fais que reprendre ce qui est développé sur cette page : https://doc.ubuntu-fr.org/variables_d_environnement

"4.1 Portée des variables
Les variables d'environnement ont une portée locale. Ce qui signifie que leur valeur est spécifique au processus dans lequel ou pour lequel elles ont été définies. Ainsi si vous ouvrez deux terminaux différents, c'est à dire deux processus bash différents, et que vous changez la valeur d'une variable d'environnement dans un terminal, ce changement n'affectera pas l'autre terminal ni aucun autre programme. Ce changement est local, il affecte le processus dans lequel il a été effectué, sans aucune influence sur les autres processus externes.

4.2 Héritage
Lorsqu'un processus enfant est créé à partir d'un processus parent, le processus enfant hérite de toutes les variables du processus parent, avec leurs valeurs. Par exemple, si on lance gedit depuis un terminal, bash le processus parent, engendre le processus enfant gedit.

En conséquence, si nous définissons la valeur de la variable d'environnement « LANG » dans un terminal, et que nous lançons depuis le même terminal gedit, celui-ci héritera de la nouvelle valeur de la variable LANG, et s'affichera donc dans une langue différente du reste des applications du système."

Enfin, la remarque sur l'interactivité n'a rien à voir avec la portée. Dans ton premier message, tu mettais en opposition l'indisponibilité d'une valeur dans un script alors que tu l'avais défini dans .bashrc.Ce que t'as précisé disedorgue, c'est que le .bashrc n'est exécuté que quand tu lances la console. Ainsi la valeur est disponible dans la console. Mais pas ses enfants. Or un script est un enfant. Donc, indisponibilité dans le script. À moins de transmettre ou exporter.

D'après mes investigations, si je déclare ma variable
variable="test"
dans .profile, celle-ci n'est pas reconnue.
Si je la déclare par
export variable="test"
là elle est reconnue en toutes circonstances (shell, terminal lancé depuis cette console, script). Normal, elle est définie globalement.

La même chose dans .bashrc, sans export, la variable est reconnue par le shell et dans un terminal lancé depuis cette console, mais pas dans un script.
Il semble donc bien que .bashrc n'est pas exécuté lorsqu'on lance un script comme l'indique disedorgue.
Avec export, elle est bien reconnue en toutes circonstances, même dans le script. Normal puisque déclarée comme variable globale.

Par ailleurs, la notion d'héritage ne semble effectivement pas pertinente, puisque c'est sa déclaration en tant que variable globale qui permet sa reconnaissance dans d'autres shell.
Corrigez-moi si je me trompe.

Et effectivement, la synthèse que je proposais dans mon message précédent ne tient pas la route.

[Flodelarab]

Je voudrais mettre en regard la fin de ta synthèse avec ton premier message.
(test.bash est le script de ton premier message)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$ variable=test
$ echo $variable
test
$ ./test.bash 
 
$ . test.bash 
test

À un caractère près ! Pas d'bol.

La commande source fait sauter la filiation. Donc pas de problème de transmission de variable à l'enfant. C'est sûr que si tu sources tes scripts, au lieu de les exécuter, tu n'as plus de problème.

[Philippe Dpt35]

Il n'y a rien de tel que la reformulation pour s'assurer que les choses ont été bien comprises.

Je propose donc une nouvelle synthèse. Dites-moi si celle-ci convient.

Les variables d'environnement ont une portée locale. Ainsi une variable déclarée dans un shell ne sera valide que pour ce shell.
Ex:
si je définis la variable
variable="test"
echo "$variable"
ne renverra le contenu de la variable que dans le shell courant
Si l'on crée le script test.sh avec pour contenu
#!/bin/bash
echo "$variable"
l'exécution du script renverra une valeur vide puisque le script s'est exécuté dans un sous-shell.
De même si je lance un terminal en ligne de commande dans la console, la variable sera inconnue dans ce sous-shell.

Pour déclarer la variable de manière globale, afin qu'elle soit accessible dans tout sous-shell, il faut la déclarer par export
export variable="test"
ou bien, si elle a déjà été déclarée :
export variable
Mais elle ne sera pas accessible depuis une autre console.

Pour disposer de cette valeur de manière permanente au niveau de la session, il faut l'inscrire dans un des fichiers d'environnement .bashrc, .bash_profile, .profile

Usage de ces différents fichiers (repris depuis doc.ubuntu-fr.org)
- ~/.profile - C'est probablement le meilleur endroit pour placer une définition de variable d'environnement. En effet, il est exécuté automatiquement par le gestionnaire de connexion lors du démarrage d'une session graphique, mais aussi lors du démarrage d'une session en mode console texte.
~/.bash_profile ou ~/.bash_login - Si l'un de ces fichiers existe, il sera exécuté par Bash préférentiellement à ~/.profile lors d'une connexion sur une console. (Bash utilisera ~/.bash_profile de préférence à ~/.bash_login). Cependant, ces fichiers n'auront par défaut aucune influence sur une session en mode graphique.
- ~/.bashrc - Du fait de la manière dont Ubuntu configure par défaut les divers fichiers de scripts, c'est sans doute l'endroit le plus facile pour définir des variables. La configuration par défaut garantit a peu près que ce fichier sera exécuté à chaque invocation de *bash* ainsi que lors de la connexion à l'environnement graphique. Cependant du point de vue des performances, ce n'est pas l'idéal car les variables seront inutilement redéfinies à chaque fois. (NdT : à chaque fois que vous ouvrez un terminal par exemple?)

Il faut la déclarer par export pour qu'elle soit disponible dans n'importe quelle console.
Attention : .bashrc n'est pas chargé lorsqu'on lance un script. Ainsi si l'on déclare la variable dans .bashrc, elle ne sera pas reconnue dans un script.
Pour disposer de ses variables d'environnement dans tout shell et sous-shell de la session, il faut donc les déclarer dans .profile avec export.

[Sve@r]

Bonjour

Les variables d'environnement ont une portée locale. Ainsi une variable déclarée dans un shell ne sera valide que pour ce shell.
Ex:
si je définis la variable
variable="test"
echo "$variable"
ne renverra le contenu de la variable que dans le shell courant
Si l'on crée le script test.sh avec pour contenu

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#!/bin/bash
echo "$variable"

l'exécution du script renverra une valeur vide puisque le script s'est exécuté dans un sous-shell.

Exact. Tu peux aussi ouvrir un shell fils par la commande bash et, dans ce sous-shell, taper echo "$variable" tu n'auras rien non plus.

De même si je lance un terminal en ligne de commande dans la console, la variable sera inconnue dans ce sous-shell.

Tu veux dire "depuis la console dans laquelle tu as écrit variable="test"" alors ok.

Pour déclarer la variable de manière globale, afin qu'elle soit accessible dans tout sous-shell, il faut la déclarer par export
export variable="test"ou bien, si elle a déjà été déclarée :
export variable

Attention au terme "global" car il sous-entend qu'il s'agit d'une unique variable (la modifier dans un fils répercute la modif dans le père). Or ce n'est pas tout à fait cela.
La commande export variable fait en sorte que cette variable sera copiée dans tous les fils futurs. Les fils ne récupérant qu'une copie, s'ils la modifient cela ne change rien pour celle d'origine.

Mais elle ne sera pas accessible depuis une autre console.

Encore une fois, il faut voir d'où est ouverte cette console. D'ailleurs tu devrais arrêter de séparer "console" et "sous-shell" car ce sont la même chose: des processus.

Pour disposer de cette valeur de manière permanente au niveau de la session, il faut l'inscrire dans un des fichiers d'environnement .bashrc, .bash_profile, .profile

Attention, ".profile" et ".bash_profile" ont le même rôle mais ne sont pas gérés par le même shell. En bash, ce n'est que ".bash_profile" qui est traité et ".profile" n'est pas pris en considération (peut-être qu'il l'est en ksh par exemple).

Attention : .bashrc n'est pas chargé lorsqu'on lance un script. Ainsi si l'on déclare la variable dans .bashrc, elle ne sera pas reconnue dans un script.

Oui mais le rôle de .bashrc n'est pas de créer des variables pour les scripts (cela foutrait un beau merdier si les scripts fonctionnaient chez X qui a un .bashrc avec variable et pas chez Y qui ne l'a pas). .bashrc c'est pour l'environnement de l'utilisateur.
Les scripts, eux, doivent être indépendants et donc définissent leurs propres variables.

4.2 Héritage
Lorsqu'un processus enfant est créé à partir d'un processus parent, le processus enfant hérite de toutes les variables du processus parent, avec leurs valeurs.

Exact. En C, tu définis un int toto=123 tu lances un fork() tu obtiens un second processus (fils) qui contient "toto=123" tandis que le processus d'origine (le père) a toujours son "toto=123". Et chaque "toto" est indépendant.

C'est donc aussi valable en shell (écrit en C). Toutefois ce comportement a été volontairement cassé (par sécurité). Ainsi seules les variables exportées (par l'utilisateur) sont copiées dans les fils.

Accessoirement il y a un détail qui ne t'a pas sauté aux yeux : puisque les scripts sont traités par les fils et que les modifications des fils ne remontent pas vers le père, comment se fait-il que les variables créées dans le ".bashrc" (un script donc) soient connues de ton environnement (environnement qui aura traité le script ".bashrc" dans un fils) ?
Je te laisse chercher (sauf si un autre intervenant te lache la solution)...

[Dens1]

C'est bon dis nous sev@r stp, ça fait depuis Septembre qu'on attend
Bon super intéressant ce post : il va falloir que je le ressasse d'ailleurs, parce que pas tout capter. Outre "la portée des variables en bash" (on l'a tous lu cette rubrique qui nous à tous laissés sur notre faim), je pense avoir capter la démarche de Philippe, c'est pas par hasard qu'il insiste sur non-interactif cad "un script" et le reste. C'est bien parce qu'on est souvent confronté au problème du truc qui marche en console et qui marche pas dans un script.

Et je dirais même plus, ma hantise, c'est de sourcer plusieurs fois le même fichier, dont x fois inutilement.

Et, mais là il va falloir que bookmark ce fil pour m'y replonger tant que j'ai pas tout compris, par exemple j'aimerais pouvoir faire remonter $variable du fils au père et même ! qu'elle soit dans l'environnement pour tous scripts qui suit, toutes consoles qui s'ouvre. C'est abuser ?

En tous cas bravos, belles synthèses belles réflexions, merci.

[Philippe Dpt35]

D'avoir fait remonter le fil m'a incité à reprendre mes notes de l'époque concernant ce problème.

Je n'ai rien retrouvé concernant la question posée par sve@r. Le suspens demeure donc !

En revanche, voici ce que j'avais noté :
Constat de septembre 23 : les variables déclarées dans .profile n'étaient pas disponibles dans les scripts.
Solution : créer un fichier avec les variables et insérer en début de script un chemin vers ce fichier en le sourçant.
Ex : source /chemin/mon-fichier-variables.sh

N'ayant pas eu à me repencher sur le problème depuis cette époque, je vous livre les choses à l'état brut, sans recul, dans le cas où ça pourrait servir à d'autres.

Les experts passant par là pourront corriger, relativiser, expliquer, ... s'ils le jugent utile !

[Dens1]

oui merci, donc on a pas tout bien compris, mais on continue, c'est beau bash

[Philippe Dpt35]

Bonjour
Accessoirement il y a un détail qui ne t'a pas sauté aux yeux : puisque les scripts sont traités par les fils et que les modifications des fils ne remontent pas vers le père, comment se fait-il que les variables créées dans le ".bashrc" (un script donc) soient connues de ton environnement (environnement qui aura traité le script ".bashrc" dans un fils) ?
Je te laisse chercher (sauf si un autre intervenant te lache la solution)...

Puisque le sujet est relancé, je me risque à une réponse : ne serait-ce pas parce que .bashrc est automatiquement lancé lorsqu'un shell est ouvert ?

[Dens1]

Puisque le sujet est relancé, ...

( ha moi j'adore les cold cases. Je suis. J'ai hâte. )

[disedorgue]

Et vous avez essayé de regarder le man de bash pour comprendre comment celui-ci gère la lecture ou non lecture des fichiers de configuration ?
Pour le man en anglais (que je conseillerais à celui du français)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

man -P 'less +/^INVOCATION' bash

[Sve@r]

Puisque le sujet est relancé, je me risque à une réponse : ne serait-ce pas parce que .bashrc est automatiquement lancé lorsqu'un shell est ouvert ?

Alors déjà oser une réponse c'est excellent. C'est prendre un risque, émettre une hypothèse, bref tenter de faire avancer les choses. Et ça c'est admirable et juste si tu t'arrêtes de lire ici tu as déjà gagné.

Maintenant si tu es intéressé et que tu continues à lire alors tu n'as pas vraiment trouvé. Le terme "lancé" est en lui-même imparfait. Imaginons par exemple un script "xxx.sh" qui contient l'instructon toto=123, tu peux le lancer autant de fois que tu le voudras, tu n'auras jamais de variable "toto" de créée. Tu peux même créer un autre script "main.sh" qui appelle ./xxx.sh; echo "$toto" cela ne changera rien, tu n'auras pas "123" à l'arrivée.

Oui c'est vrai que.bashrc est appelé (lancé si tu veux) à chaque shell (et ceci même dans des shells totalement inattendus (exemple dans ":.sh" sous "gvim"). Mais tout tient dans la façon dont il est appelé.
En fait le .bashrc est "sourcé", c'est à dire inclus, littéralement inclus dans le shell ouvert. Cela se fait par l'instruction source qui va... faire comme si le script était tapé par l'utilisateur. Et dans ce cas, il ne s'exécute pas dans un fils mais dans le shell courant.
Un exemple amusant : tu crée un script "xxx.sh" qui contient cette unique instruction; exit 0. Puis tu appelles ./xxx.sh dans un premier temps ; puis ensuite source xxx.sh. Et tu regardes la différence de comportement...

C'est bon dis nous sev@r stp, ça fait depuis Septembre qu'on attend

Bah il n'y a pas que moi qui connait Unix. Je suis d'ailleurs étonné que personne n'ait apporté la réponse depuis le temps.