[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [debutant] Configurer variables d'environnement
On Tue, Jul 27, 1999 at 10:46:18AM +0200, Alain Nissen wrote:
> Pascal Bleser wrote:
> > Toutes les variables du shell sont des variables d'environnement.
> > Simplement, il faut distinguer les variables exportées et les variables
> > non-exportées. Chaque var.d'env. a un flag d'exportation mis à vrai ou faux.
> C'est une question de définition de "variable d'environnement";
> personnellement, j'ai toujours cru lire dans les bouquins et autres
> pages de manuels Unix qu'une variable d'environnement était, par
> définition, une variable exportée. Mais je peux me tromper :)
Non, de fait, tu fais bien de me corriger.
Les variables d'environnement ne sont que les variables exportées.
Bien vu ;))
> A priori je peux comprendre ta définition dans le cadre d'un shell
> compatible Bourne (sh, bash, ksh), puisqu'une variable est locale
> jusqu'à ce qu'elle soit exportée par la commande export; mais dans le
> cadre d'un shell de type C (csh, tcsh), ce sont deux commandes
> différentes, "set" et "setenv", qui définissent une variable locale et
> une variable exportée.
Oui. Strictement parlant, export ne fait que mettre le flag "export" sur
la variable. Ce n'est que par une extension non-standard sh du bash et du
ksh qu'on peut faire export blah=foo - en principe, il faudrait faire
blah=foo; export blah
Notez qu'on peut aussi dé-exporter une variable en faisant:
export -n blah
On peut aussi, lorsque l'on définit toute une floppée de variables à exporter
(p.ex. dans ~/.profile), utiliser le flag "auto-export":
set -a # autoexport activé
blah=foo # blah sera exportée automatiquement
...
set +a # autoexport désactivé
> Ceci dit, je voudrais aussi rajouter un mot à propos des variables
> d'environnement (exportées) dans les shells compatibles Bourne : il
> existe également la notion de variable d'environnement (exportée)
> *temporaire*, limitée à un seul processus-fils du shell; par exemple, la
Ah oui, bonne idée, je n'y avais pas pensé :)
> ligne suivante d'un shell-script
> variable=valeur commande arg1 arg2 ...
Exact. Et on peut aussi en définir plusieurs d'un coup:
BLAH=1 FOO=2 BAR="hello world" ls -AlF
> provoque l'exécution de "commande" avec en arguments "arg1", "arg2, ...
> et la définition temporaire d'une variable d'environnement exportée :
> seule la commande "toto" (et ses processus-fils éventuels) connait la
> définition de cette variable; ni le shell, ni les autres processus
> futurs démarrés par le shell ne la connaitront.
> Quelle est l'utilité de cette notation ? ça permet de diminuer la
> mémoire occupée par la zone d'environnement dans chaque processus. En
> effet, définit dans un shell-script une variable d'environnement qui ne
> sera vraiment consultée que par un seul processus-fils est du gaspillage
> de mémoire, puisque tous les processus-fils du shells et tous leurs
> descendants éventuels vont en hériter "pour rien".
Oui et puis ça permet de passer des paramètres dans certains cas et de
modifier le comportement. Un exemple: des Makefiles qui utilisent la variable
"CFLAGS", comme c'est très souvent le cas.
Et bien, pour modifier la variable, on peut faire:
CFLAGS="-O6 -mpentium" make
pour optimiser à l'extrème ou bien
CFLAGS="-g" make
pour créer une version debug (le contenu de CFLAGS est passé comme paramètres
au compilateur C ou C++).
Encore un petit ajout: pour avoir la liste des variables d'environnement définies,
dans votre shell, tapez "env".
Pour consulter la liste de variables d'environnement bien à votre aise: env|sort|less
Effectivement, pour souligner la remarque d'Alain:
a=5; env|grep ^a=
ne donne rien, alors que
export a=5; env|grep ^a=
donne bien "a=5" ;)
(pour l'anecdote, "^" dans grep signifie "au début de la ligne").
Certaines variables d'environnement se prêtent particulièrement bien à ce petit jeu,
p.ex. PATH, MANPATH et INFODIR; celles-ci contiennent une liste de répertoires
(séparés par :) qui sont chacun parcourus à la recherche resp. d'éxécutables, de
manpages et de pages GNU info. Si vous avez des manpages dans un répertoire un peu
inhabituel et que vous n'avez pas fait un truc du genre
export MANPATH="$MANPATH:/opt/mysql/man"
dans votre ~/.profile, vous pouvez toujours faire:
MANPATH="/opt/mysql/man" man mysqld
--
-o) Pascal Bleser | Instead of giving Windows
/\\ C++/UNIX Development | the "three-finger-salute",
_\_v ATOS Payment Systems | give it the "one-finger-
Aachen, Germany | goodbye" {jfk/propaganda}
<pbleser@atos-group.com>--------------<guru@linuxbe.org>
o---------------------------------------------------o
| -o) |
| /\\ Don't fear the penguin - http://linuxbe.org |
| _\_v The Newbie's site http://newbie.linuxbe.org |
o---------------------------------------------------o