Discussion :

[developpeurP00]

Bonjour

Je souhaiterais qu'on m'explique la différence entre ces trois instructions shell :

Code :

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

variable=valeur commande

Code :

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

env variable=valeur commande

Code :

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

variable=valeur ;  commande

Merci

[Sve@r]

Bonjour

Code :

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

variable=valeur ;  commande

Le point-virgule sépare les instructions. Ca équivaut à

Code bash :

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

1
2
variable=valeur
commande

En général je m'en sers pour les "if" et "while". Je trouve plus sympa d'écrire

Code bash :

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

1
2
3
while truc; do
	...
done

que

Code bash :

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

1
2
3
4
while truc
do
	...
done

Pour les deux autres j'en ai aucune idée sauf que chez-moi, aucune des deux n'a fonctionné. Je n'ai pas eu d'erreur, la commande s'est exécutée mais ma variable est restée vide.

[Christophe]

Code :

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

env variable=valeur commande

va modifier la valeur de variable avec valeur ou affecter la valeur valeur à variable le temps de l’exécution de commande.

[Sve@r]

va modifier la valeur de variable avec valeur ou affecter la valeur valeur à variable le temps de l’exécution de commande.

Oui j'y avais pensé mais j'ai testé env xxx=123 echo $xxx j'ai rien eu...

[developpeurP00]

Bonjour
Le point-virgule sépare les instructions. Ca équivaut à

Code bash :

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

1
2
variable=valeur
commande

.

Ok pour la troisième instruction, mais je ne comprends pas le comportement des deux autres instructions. 'variable' reste vide !
Pourtant, je rencontre beaucoup ce syntaxe dans les codes shell.

exemple :

Code :

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

 sudo env path=$path commande

[balkany]

Oui j'y avais pensé mais j'ai testé env xxx=123 echo $xxx j'ai rien eu...

C'est parce que le shell développe les variables avant d'exécuter la commande, donc au moment où il considère l'assignation xxx=123 la variable xxx n'existe plus dans l'expression à droite.
Ceci serait différent :

Code :

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

env xxx=123 sh -c 'echo $xxx'

La première et la deuxième commandes en OP modifient toutes les deux l'environnement de commande avant de l'exécuter. La différence est que la première utilise une syntaxe shell pour le faire, alors que la deuxième utilise la commande env, qui permet un contrôle plus fin, et qui ne nécessite pas d'interpréteur shell pour fonctionner (donc elle peut être directement utilisée dans un lanceur par exemple).

[developpeurP00]

Je commence à comprendre. C'est un début. Mais, pourquoi avec cette instruction ci-dessous c'est différent ?

Code :

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

env xxx=123 sh -c 'echo $xxx'

Je peux dire ici aussi que le shell va développer xxx dans la partie sh -c 'echo $xxx' avant d'exécuter l'assignation xxx=123 ! Je ne vois pas la différence

Autre question : s'il te plaît. peux-tu détailler cette réponse :

La commande env permet un contrôle plus fin, qui ne nécessite pas d'interpréteur shell pour fonctionner (donc elle peut être directement utilisée dans un lanceur par exemple)

[Sve@r]

Je peux dire ici aussi que le shell va développer xxx dans la partie sh -c 'echo $xxx' avant d'exécuter l'assignation xxx=123 ! Je ne vois pas la différence

Oui c'est un peu subtil
Dans l'écriture xxx=123 echo $xxx, au moment où tu valides ta commande par <return> le shell remplace "$xxx" par sa valeur. Et c'est cette valeur qui est envoyée à "echo". Mais cette valeur n'existe pas encore puisque le processus "echo" n'existe pas encore. Donc ça équivaut à

Code bash :

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

1
2
xxx=123
echo

Dans l'écriture xxx=123 sh -c 'echo $xxx' ce sont les quotes simples qui font toute la différence. Parce que les quotes simples désactivent tous les métacaractères y compris le métacaractère "$" (teste echo '$HOME' puis echo "$HOME" par exemple).
Donc là, le shell ne voit pas de variable à développer. Il voit juste une bête string à envoyer à "echo".
Et c'est quand le processus "echo" est exécuté que là, la variable "$xxx" prend tout son sens. Mais là, la variable existe.

[balkany]

Je peux dire ici aussi que le shell va développer xxx dans la partie sh -c 'echo $xxx' avant d'exécuter l'assignation xxx=123 ! Je ne vois pas la différence

Non tu ne peux pas le dire (enfin tu peux mais c'est faux ), car l'emploi de guillemets simples empêche le développement de variables par le shell.
Là tu pourrais le dire :

Code :

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

env xxx=123 sh -c "echo $xxx"

Autre question : s'il te plaît. peux-tu détailler cette réponse :
La commande env permet un contrôle plus fin, qui ne nécessite pas d'interpréteur shell pour fonctionner (donc elle peut être directement utilisée dans un lanceur par exemple)

Voir man env pour le contrôle plus fin, env permet par exemple d'enlever une variable de l'environnement avant exécution.

Pour les lanceurs je parle des fichiers .desktop qu'on utilise dans les environnements de bureau.
Dans ces fichiers, tu ne peux pas mettre directement xxx=123 commande comme commande à exécuter, car cette syntaxe nécessite un interpréteur shell (c'est du code shell).
Mais tu peux mettre env xxx=123 commande, car ici l'assignation xxx=123 est un argument de la commande env, ça n'est pas du code shell.

[developpeurP00]

Excellent. Tout ça c'est excellent

Je pense que j'ai compris, mais confirmez le :-)

Le but final du sujet que j'ai posté est pour comprendre le fonctionnement de ces deux commandes :

Code :

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

sudo PATH=$PATH  script  # ne fonctionne pas  : le chemin du script est inconnu

Code :

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

sudo env PATH=$PATH  script  # fonctionne

1) Dans les deux instructions, le shell va développer la valeur $PATH avant d'exécuter le script. Donc ici, c'est la valeur PATH de l'utilisateur lambda (et non du root) qui est envoyée (correct ?)

2) Cependant, dans la première instruction, l'assignation PATH=$PATH est locale et n'est pas exporté vers le script, car ce dernier lance un processus fils qui n'est plus celui du shell actif courant (correct ?)
3 ) La deuxième fonctionne, parce que comme tu as dit, la commande env est spéciale et permet d'exporter les variables aux processus fils (dans notre cas, c'est notre script) (correct ?)
4) La deuxième instruction est équivalente à 100% à :

Code :

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

sudo sh -c "export  PATH=$PATH ; script"

et non à :

Code :

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

sudo sh -c 'export  PATH=$PATH ; script'

Merci

[Sve@r]

Code :

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

sudo PATH=$PATH  script  # ne fonctionne pas  : le chemin du script est inconnu

Code :

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

sudo env PATH=$PATH  script  # fonctionne

Bizarre, car les deux doivent fonctionner.
Exemple: script "toto.sh"

Code bash :

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

1
2
3
#!/usr/bin/env bash
 
echo "xxx=[$xxx]"

De là

Code :

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

1
2
3
4
5
$ xxx=123 ./toto.sh
xxx=[123]
$ env xxx=123 ./toto.sh
xxx=[123]
$

Ce n'est pas "env" qui envoie la variable au script, c'est le fait que le script soit sur la même ligne d'instruction.

Dans les deux instructions, le shell va développer la valeur $PATH avant d'exécuter le script. Donc ici, c'est la valeur PATH de l'utilisateur lambda (et non du root) qui est envoyée (correct ?)

Là oui. Le PATH de l'user est copié dans un "PATH fils" et c'est ce "PATH fils" qui est utilisé dans le sudo.

Cependant, dans la première instruction, l'assignation PATH=$PATH est locale et n'est pas exporté vers le script, car ce dernier lance un processus fils qui n'est plus celui du shell actif courant (correct ?)
La deuxième fonctionne, parce que comme tu as dit, la commande env est spéciale et permet d'exporter les variables aux processus fils (dans notre cas, c'est notre script) (correct ?)

Non. Les deux devraient fonctionner.
Modification toto

Code bash :

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

1
2
3
#!/usr/bin/env bash
 
echo "PATH=[$PATH]"

De là

Code :

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

1
2
3
4
5
6
7
$ PATH="/usr/bin" ./toto.sh 
PATH=[/usr/bin]
$ env PATH="/usr/bin" ./toto.sh 
PATH=[/usr/bin]
$ ./toto.sh
PATH=[/home/moi/bin:/usr/local/pgsql/bin:/usr/local/pgadmin3/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/moi/bin]
$

Le PATH est bien transmis à "toto.sh".
Après il peut y avoir d'autres trucs. Par exemple le PATH est un élément assez important et même utilisé de façon standard, doit être exporté car les fils en ont besoin. Alors utilisé de cette façon? Et avec un "sudo" en plus qui peut rajouter des effets de bord éventuels???

[developpeurP00]

Tu as raison et je me suis trempé. Le chemin PATH de l'utilisateur lambda est transmis dans les deux instructions :

Code :

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

sudo PATH=$PATH script.sh

et

Code :

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

sudo env PATH=$PATH script.sh

Mais je ne comprends pas pourquoi la première instruction ne fonctionne pas sachant que le chemin du script.sh est inclus dans l'environnement PATH de lambda. Ça retourne l'erreur comme ceci

Code :

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

sudo: script.sh : commande introuvable

Testez avec une commande qui existe dans le chemin PATH de lambda et non du root et vous verrez !

Quelqu'un peut nous expliquer ?

[Sve@r]

Testez avec une commande qui existe dans le chemin PATH de lambda et non du root et vous verrez !

Exact (viens de le faire). M'a suffit de copier "toto.sh" dans mon bin. De là

Code bash :

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

1
2
3
4
5
$ sudo PATH=$PATH toto.sh
[sudo] Mot de passe de moi*: 
sudo: toto.sh*: commande introuvable
$ sudo env PATH=$PATH toto.sh
PATH=[/home/moi/bin:/usr/local/pgsql/bin:/usr/local/pgadmin3/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/moi/bin]

Ok on est d'accord, ça ne fonctionne pas. C'est parce que le PATH n'est pas encore modifié quand root tente d'appeler "toto.sh" et ne sait donc pas où le trouver.

Quelqu'un peut nous expliquer ?

Oui. Suffit de coupler cet exemple avec celui de balkany.

Je teste ceci (grand merci à balkany qui m'a montré la syntaxe). Et là...

Code bash :

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

1
2
$ sudo PATH=$PATH sh -c 'toto.sh'
PATH=[/home/moi/bin:/usr/local/pgsql/bin:/usr/local/pgadmin3/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/moi/bin]

De là ça recolle avec l'idée de départ qu'a montré balkany avec son excellent exemple. Le shell développe PATH avant d'appeler toto.sh. Sauf que le PATH de root ne connait pas le chemin de toto.sh (qui est dans mon bin et non dans celui de root) donc root ne peut pas exécuter toto.sh
Tandis qu'avec sh -c, là le PATH est maintenant connu du process "sh" qui, de fait, sait aller chercher "toto.sh". En fait, tout se résume à "la variable n'est modifiée que dans le process demandé et pas avant".

[developpeurP00]

Ah !

Mais pourquoi @Sve@r ?

C'est parce que le Shell va tenter d'exécuter "PATH=$PATH toto.sh" en une seule fois toute la commande comme seul bloc ?, c'est bien ça ?

Parce que moi, je vois "PATH=$PATH toto.sh" comme succession de deux commandes " "PATH=$PATH puis toto.sh " donc le script toto.sh " aura le nouveau chemin PATH modifié. (Je me trempe alors)

[Sve@r]

C'est parce que le Shell va tenter d'exécuter "PATH=$PATH toto.sh" en une seule fois toute la commande comme seul bloc ?, c'est bien ça ?

Oui. Le PATH ne sera modifié que dans le processus "toto.sh" mais si le procesuss ne peut pas être lancé parce que le shell ne sait pas où trouver toto.sh...
C'est la base. Ensuite il y a "env" qui doit jouer un rôle là dedans. Probablement (hypothèse) parce que "env" a pour but de modifier l'environnement et que, de fait, là la variable est alors connue permettant alors de lancer "toto.sh"...

Parce que moi, je vois "PATH=$PATH toto.sh" comme succession de deux commandes " "PATH=$PATH puis toto.sh "

Non. Deux commandes distinctes c'est soit sur deux lignes (avec un <return> par ligne), soit avec un point-virgule entre les deux.

[developpeurP00]

Ça avance :

Mais en suivant ton raisonnement pourquoi alors :

Code :

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

sudo env PATH=$PATH toto.sh

#fonctionne

Je peux dire aussi (comme tu l'as dit : c'est un extrait de ton message) :

le PATH n'est pas encore modifié (avec env PATH=$PATH ) quand root tente d'appeler "toto.sh" et ne sait donc pas où le trouver.

[Sve@r]

Je peux dire aussi (comme tu l'as dit : c'est un extrait de ton message) :

le PATH n'est pas encore modifié (avec env PATH=$PATH ) quand root tente d'appeler "toto.sh" et ne sait donc pas où le trouver.

Oui mais j'ai rajouté "Ensuite il y a "env" qui doit jouer un rôle là dedans"...

[developpeurP00]

Ah, d'accord. Merci tout le monde. J'ai compris beaucoup de choses grâce à vous. Mais pour arriver à 100 % de compréhension :-) , je chercherai dans le man de la commande env pour comprendre pourquoi

Code :

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

sudo env PATH=$PATH toto.sh

Fonctionne.

C'est la seule étape qui reste

Balkani a essayé peut-être de l'expliquer, mais je ne l'ai pas compris

Citation Balkani : Voir man env pour le contrôle plus fin, env permet par exemple d'enlever une variable de l'environnement avant exécution.

[Sve@r]

Oui c'est vrai que "env" est un outil à décortiquer. Le man dit "env - run a program in a modified environment". Donc c'est en quelque sorte une espèce de "bac à sable". Et couplé avec un var=truc ça donne (ou ça "doit donner") un environnement dans lequel la variable existe, contrairement aux autres essais faits sans.

[disedorgue]

Ça avance :

Mais en suivant ton raisonnement pourquoi alors :

Code :

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

sudo env PATH=$PATH toto.sh

#fonctionne

Je peux dire aussi (comme tu l'as dit : c'est un extrait de ton message) :

le PATH n'est pas encore modifié (avec env PATH=$PATH ) quand root tente d'appeler "toto.sh" et ne sait donc pas où le trouver.

Pour moi, ici root n'appelle pas toto.sh mais env qui appelle toto.sh