variable d'environnement

6 views
Skip to first unread message

abbassi chifa

unread,
Jun 25, 2011, 7:28:37 AM6/25/11
to ENSI_LPI2011
Bonjour,
J ai une question si vous pouvez m aider merci d'avance

Si on a une variable d'environnement qu' on a changé son contenu dans
un script shell en faisant exit quelle serait la valeur de la variable
d'environnement est ce la valeur modifiée ou l ancienne

meilleures salutations

kamel sanai

unread,
Jun 25, 2011, 8:57:59 AM6/25/11
to ensi_l...@googlegroups.com

Généralement pour ajouter/modifier une variable d’environnement d’une façon permanente, on édite le fichier /etc/bash.bashrc (sous ubuntu).

Puis :  

sudo gedit /etc/bash.bashrc

à la fin du fichier, tu ajoutes :

            VARIABLE=VALEUR

export VARIABLE

Après tu lance un nouveau terminal : echo $VARIABLE

Firas Aloui

unread,
Jun 25, 2011, 9:09:17 AM6/25/11
to ensi_l...@googlegroups.com
generallement le script lance un autre shell donc la modification ne touche pas le shell dans le quelle ta lancé le script
(à verifier )
--
Firas ALOUI
Élève Ingénieur de l'École Nationale des Sciences  de l'Informatique TUNISIE
Phone:  +216 23 206 692

abbassi chifa

unread,
Jun 25, 2011, 9:42:10 AM6/25/11
to ENSI_LPI2011
Soit la suite des commandes suivantes : $ var=3 $ export var $ bash $
var=`expr $var - 1` $ exit exit $ echo $var Quel est le résultat de la
dernière commande ?
la réponse correcte était 3
Pourquoi?

On Jun 25, 3:09 pm, Firas Aloui <aloui.fi...@gmail.com> wrote:
> generallement le script lance un autre shell donc la modification ne touche
> pas le shell dans le quelle ta lancé le script
> (à verifier )
>
> Le 25 juin 2011 13:57, kamel sanai <allisahme...@gmail.com> a écrit :
>
> > Généralement pour ajouter/modifier une variable d’environnement d’une façon
> > permanente, on édite le fichier /etc/bash.bashrc (sous ubuntu).
>
> > Puis :
>
> > sudo gedit /etc/bash.bashrc
>
> > à la fin du fichier, tu ajoutes :
>
> >             *VARIABLE=VALEUR*
>
> > *export VARIABLE*

kamel sanai

unread,
Jun 25, 2011, 10:06:09 AM6/25/11
to ensi_l...@googlegroups.com


tu as exporté la variable juste après l'assignation de la valeur 3 . Après toute autre modification tu devras exporter une autre fois la variable pour voir effectivement la modification. Si tu le fais pas la variable ne change pas . Je sais pas, normalement s'est la seule raison pour laquelle la variable n'a pas changé. tu pourras l'essayer.

Firas Aloui

unread,
Jun 25, 2011, 10:53:49 AM6/25/11
to ensi_l...@googlegroups.com
comme je vien de le dire la decrémentation de la variable s'ait faite dans un deuxiéme shell c'est pour sa que sa valeur ne change pas

Le 25 juin 2011 15:06, kamel sanai <allisa...@gmail.com> a écrit :


tu as exporté la variable juste après l'assignation de la valeur 3 . Après toute autre modification tu devras exporter une autre fois la variable pour voir effectivement la modification. Si tu le fais pas la variable ne change pas . Je sais pas, normalement s'est la seule raison pour laquelle la variable n'a pas changé. tu pourras l'essayer.



Ghazi TEKAYA

unread,
Jun 25, 2011, 11:01:42 AM6/25/11
to ensi_l...@googlegroups.com
Les shell fils héritent les variables d'environnement du shell parent et pas l'inverse. 
Donc lorsqu'on utilise "exit", on va retourner au shell parent sans mettre à jour les variables d'environnement.

Ahmed Abida

unread,
Jun 25, 2011, 11:57:16 AM6/25/11
to ensi_l...@googlegroups.com
Bonjour,
J'ai une question qui concerne les redirections et les pipes.
J'ai trouvé dans le livre "LPI Linux Certification IN A NUTSHELL" les exemples suivant: (page 125)
  • "cmd >> file 2>&1: Append both stdout and stderr to file", on peut comprendre de cet exemple que &1 représente le premier argument ou le premier mot après la commande "cmd"
  • Dans un autre exemple il y a ceci: "cmd1 2>&1 | cmd2 : Pipe stdout and stderr from cmd1 to cmd2". Dans cet exemple alors &1 n'a pas la même signification que la précédente!!
Merci de m'indiquer ce que signifie générale de &1 (et &2 si elle existe)

Cordialement
--
Ahmed ABIDA
Computer Science Engineering Student, ENSI TUNISIA

Firas Aloui

unread,
Jun 25, 2011, 12:07:14 PM6/25/11
to ensi_l...@googlegroups.com
bonjour,
en fait le &1 ne représante pas le premier argument.deja le symbole c'est >& et il permet de lier les canaux standard.
2 >& 1 permet de lier la sortie standard (1) et la sorti d erreur (2) dans la sortie standard.

Ahmed Abida

unread,
Jun 25, 2011, 12:18:28 PM6/25/11
to ensi_l...@googlegroups.com
OK merci bien pour la réponse :)
PS: dans les pipes, seuls les stdout passent à la 2ème commande et pas les outputs de stderr. exemple:
$ find /etc/ -name "*.conf" -maxdepth 1 | wc -l => va afficher un message d'erreur puis le nombre des fichiers qui finissent par .conf dans /etc, ce qui explique le fait d'utiliser 2>&1 pour la redirection de stderr.
Merci encore une fois Firas

Firas Aloui

unread,
Jun 25, 2011, 12:31:11 PM6/25/11
to ensi_l...@googlegroups.com
oui voila ta tous compris :) you're welcome any time si t a d autre question peut je pourai t'aider

abbassi chifa

unread,
Jun 26, 2011, 6:41:32 AM6/26/11
to ENSI_LPI2011

Il est possible d’exécuter des commandes dans un sous-shell sans
passer par un script. En effet, là où une
commande (ou une suite de commandes) est admise, on peut écrire la
construction spéciale :
(commande)
où commande peut être n’importe quelle suite de commandes.
Cette construction a les mêmes caractéristiques qu’un bloc formé par
des accolades, à ceci près que la com-
mande sera exécutée dans un sous-shell, alors qu’un bloc ne provoque
pas de création d’un sous-shell. Tout
comme un bloc, le sous-shell créé pour exécuter commande dispose de
ses propres entrées/sorties qui peuvent
être redirigées.
Ce qui distingue un bloc d’un sous-shell est que le sous-shell dispose
de son propre environnement. À sa
création, il hérite d’une copie totale 1 de l’environnement de son
père.
- C’est une différence notable avec les processus créés pour exécuter
une commande (ou un script)
qui n’héritent pas d’une copie des variables locales ou des alias du
père.
Disposant de son propre environnement, toute modification du
répertoire de travail et toute création/modification
de variables (y compris d’environnement), de fonctions ou d’alias
opérée dans un sous-shell n’a aucune incidence
sur l’environnement du père qui reste inchangé.
i Les sous-shells créés pour la substitution de commande, ainsi que
les commandes
lancées en tâche de fond disposent aussi d’une copie totale de
l’environnement de leur père.
L’utilisation des sous-shells créés avec les parenthèses est assez
marginale et n’a de sens que si on souhaite
exécuter du code qui modifie l’environnement, alors que l’on ne veut
pas modifier l’environnement du shell
courant
Exemples :
$ tab=(un deux trois)
$ var=blablabla
$ function ecrire { echo "($1) tab: ${tab[*]} et var : $var"; }
$ (ecrire fils) ; ecrire pere
(fils) tab: un deux trois et var: blablabla
(pere) tab: un deux trois et var: blablabla
ê on voit que le fils "connaît" le tableau tab, la variable var et la
fonction ecrire
$ (var=xxxx ; ecrire fils) ; ecrire pere
(fils) tab: un deux trois et var: xxxx
(pere) tab: un deux trois et var: blablabla
ê on voit que la modification de var par le fils n’est effective que
pour ce dernier
$ export IFS
$ (IFS=’,’ ; var=xxxx ; ecrire fils) ; ecrire pere
(fils) tab: un,deux,trois et var: xxxx
(pere) tab: un deux trois et var: blablabla
ê on voit que même si IFS est rendue d’environnement, sa modification
dans le fils n’affecte pas le
père.
Reply all
Reply to author
Forward
0 new messages