Demande d'explication : affectation précédant une commande

Version imprimable

Voir 40 message(s) de cette discussion en une page

22/07/2023, 14h57
papajoker

bonjour

Citation:

Envoyé par developpeurP00

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

si le but ici est juste d'utiliser $PATH avec sudo, tu peux aussi lire le man de sudo (--preserve-env, ...)
Et, le passage "particulier" de variable d'environnement à cette commande est décrit dans ce même man.
22/07/2023, 15h50
developpeurP00

Citation:

Envoyé par disedorgue

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

et donc ça change quoi ? en plus ça revient à la même chose (non ? je ne suis sûr) car c'est root qui exécute la commande 'env' qui appelle à son tour le script toto.sh
22/07/2023, 15h56
developpeurP00

Citation:

Envoyé par papajoker

bonjour

si le but ici est juste d'utiliser $PATH avec sudo, tu peux aussi lire le man de sudo (--preserve-env, ...)
Et, le passage "particulier" de variable d'environnement à cette commande est décrit dans ce même man.

La solution existe avec "sudo env PATH=$PATH toto.sh" mais il est important de comprendre pourquoi une solution fonctionne et l'autre non. Je dois corriger un grand script qui bogue à cause de ce problème (des commandes invalides non reconnues) et on m'a chargé d'expliquer les raisons de ce bug dans un rapport
22/07/2023, 16h34
balkany

Citation:

Envoyé par developpeurP00

La solution existe avec "sudo env PATH=$PATH toto.sh" mais il est important de comprendre pourquoi une solution fonctionne et l'autre non.

C'est propre à env, et peut-être même à GNU env :

Citation:

Envoyé par https://www.gnu.org/software/coreutils/manual/coreutils.html#env-invocation

Modifications to PATH take effect prior to searching for command.

sudo ne fonctionne manifestement pas comme ça.
22/07/2023, 17h53
papajoker
Citation:

Envoyé par developpeurP00

pour comprendre le fonctionnement de ces deux commandes :

Code:

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

Si je comprends bien ...
- ton problème n'est pas de passer la variable d'environnement dans ton script appelé par sudo
- dans ton script principal, en fait $PATH n'est PAS ta variable d'environnement
Tu modifies $PATH dans ton script principal ? (avant ton code donné)
Ton problème est que tu ne sais pas modifier ta variable d'environnement ? donc ton script principal ne trouve pas le second script dans cette variable d'environnement

Ce nouveau PATH doit être très temporaire ???
PATH="$NEWPATH" sudo toto.sh PATH="$PATH:/nouveau dir/bin" sudo toto.sh.
ou,
la bonne question initiale était simplement comment changer une variable d'environnement dans un script (et ces sous-scripts) ...
22/07/2023, 21h00
foetus
Citation:

Envoyé par papajoker

Si je comprends bien ...

En déroulant le fil de discussion :mrgreen: on est passé de variable=valeur commande (assez générique) à variable/[commande, prog ou script param].

Je ne suis pas expert en Linux :mrgreen: mais :
1. lorsque tu remplaces 1 truc simple et universel par 1 truc tordu normal que lorsque cela marche ou pas tu ne peux pas vraiment expliquer pourquoi (ici on peut voir cela comme 2 threads concurrents qu'on veut dire "thread 1 puis thread 2")
2. lorsque dans 1 commande simple (lancer 1 script) tu es obligé de créer 1 """sous shell""", c'est qu'il y a quelque chose de mauvais :aie: :aie: (avec env ou carrément avec sh -c 'XXXX')
22/07/2023, 21h15
Sve@r

Citation:

Envoyé par developpeurP00

et on m'a chargé d'expliquer les raisons de ce bug dans un rapport

Donne leur l'URL de ce topic...:aie:

Citation:

Envoyé par foetus

En déroulant le fil de discussion :mrgreen: on est passé de variable=valeur commande (assez générique) a variable/[commande, prog param].

En fait, c'est "env" qui fait que ça marche mais en même temps, qui fout la zone dans la compréhension. Et avec le fait que la variable modifiée soit justement le PATH (variable assez primordiale dans la gestion des processus) ça aide pas non plus.
22/07/2023, 23h56
disedorgue
Citation:

Envoyé par developpeurP00

et donc ça change quoi ? en plus ça revient à la même chose (non ? je ne suis sûr) car c'est root qui exécute la commande 'env' qui appelle à son tour le script toto.sh

C'est simplement parce que vous n'avez pas compris comment fonctione la syntaxe:

Code:

variable=valeur commande

cette syntaxe crée une variable "locale" à la commande de DROITE , donc sudo ne voit pas l'affectation de PATH, par contre pour la commande env , c'est différent, car pour elle c'est un paramètre qu'elle doit tenir compte et dont c'est le boulot.
Code:

1 2 3 $ env --help Utilisation*: env [OPTION]... [-] [NOM=VALEUR]... [COMMANDE [ARG]...] Initialiser chaque NOM à VALEUR dans l'environnement et exécuter COMMANDE.
23/07/2023, 10h33
balkany

Citation:

Envoyé par disedorgue

C'est simplement parce que vous n'avez pas compris comment fonctione la syntaxe:

Code:

variable=valeur commande

cette syntaxe crée une variable "locale" à la commande de DROITE , donc sudo ne voit pas l'affectation de PATH, par contre pour la commande env , c'est différent, car pour elle c'est un paramètre qu'elle doit tenir compte et dont c'est le boulot.

Ce que tu dis est vrai pour la syntaxe variable=valeur sudo commande, mais pas pour la syntaxe sudo variable=valeur commande. Dans ce dernier cas, variable=valeur est un argument de sudo comme il l'est pour env, et donc sudo pourrait le traiter comme le fait env (cf. https://www.developpez.net/forums/d2.../ ), mais elle ne le fait pas.

Non, soit tu as fait une typo et inversé tes 2 commandes sudo dans ton explication (ce qui serait plus logique pour moi):

Code:

PATH=$PATH sudo commande

ceci ne fonctionne pas car sudo par mesure de sécurité ne tient pas compte de l'environnement appelant

Code:

sudo PATH=$PATH commande

ne permet pas à sudo de trouver la commande car on lui dit juste de fournir une variable à la commande mais pas de l'intégrer dans son env.
pour preuve:
Code:

1 2 3 #!/bin/bash echo $PATH
Code:

1 2 3 4 5 6 7 8 $ echo $PATH /opt/disedorgue/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin $ ./pre.sh /opt/disedorgue/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin $ PATH=/bin ./pre.sh /bin $ echo $PATH /opt/disedorgue/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
comme on peut le voir ici, PATH n'est pas modifié dans mon shell appelant (c'est pareil pour sudo)

23/07/2023, 11h31
Sve@r

Citation:

Envoyé par disedorgue

Code:

PATH=$PATH sudo commande

ceci ne fonctionne pas car sudo par mesure de sécurité ne tient pas compte de l'environnement appelant

Ah, ça je savais pas :applo:

Citation:

Envoyé par disedorgue

Code:

sudo PATH=$PATH commande

ne permet pas à sudo de trouver la commande car on lui dit juste de fournir une variable à la commande mais pas de l'intégrer dans son env.

Ca oui je l'avais déjà décrit ici.
D'où sudo PATH=$PATH sh -c 'commande' afin que ce soit "sh" qui lance la commande ; sh processus déjà lancé à ce moment là donc connaissant le PATH modifié. 8-)
23/07/2023, 14h39
N_BaH

ça peut être contourner avec --perserve-env[=LIST] ?
23/07/2023, 15h02
Sve@r
Pense pas.
En reprenant mon "toto.sh" copié dans mon bin, j'ai tenté...
Code:

1 2 sudo --preserve-env=PATH toto.sh sudo --preserve-env=PATH PATH=$PATH toto.sh
... mais rien n'a réussi.

En revanche, en modifiant "toto.sh" pour lui faire afficher "$var", puis en écrivant export var=123, alors sudo --preserve-env=var ./toto.sh fonctionne.
Donc le "--preserve-env" c'est pour transmettre au fils, pas pour permettre au PATH d'évoluer afin de pouvoir créer ce fils.
23/07/2023, 15h10
N_BaH

Citation:

Envoyé par papajoker

si le but ici est juste d'utiliser $PATH avec sudo, tu peux aussi lire le man de sudo (--preserve-env, ...)
Et, le passage "particulier" de variable d'environnement à cette commande est décrit dans ce même man.

:oops:

Citation:

Envoyé par Sve@r

le "--preserve-env" c'est pour transmettre au fils, pas pour permettre au PATH d'évoluer afin de pouvoir créer ce fils.

ah, d'accord !
23/07/2023, 18h45
balkany

@disedorgue: je maintiens :)
Cette syntaxe a besoin d'être interprétée par un shell: variable=valeur sudo commande, et ce que fait le shell est d'ajouter variable=valeur à l'environnement de la commande sudo commande avant de la lancer.
Le fait que sudo ignore l'environnement appelant est un autre problème.

Cette syntaxe n'a pas besoin d'être interprétée par un shell: sudo variable=valeur commande, car variable=valeur est un argument de la commande sudo (et commande en est un autre argument), tout comme il est un argument de la commande env dans les posts précédents.
Le fait que sudo traite cet argument "comme le fait le shell" (manifestement) et non pas comme le fait env, est en quelques sortes accidentel : essentiellement c'est un argument, et sudo pourrait en faire autre chose.

C'est cette distinction que je voulais faire, mais pour le reste je constate comme vous le comportement démontré.
23/07/2023, 20h14
disedorgue

Pour le premier cas, on est d'accord, c'est un problème inhérent à sudo.
Pour le deuxième cas, tu auras le même souci que sudo via Bash ou autre shell car la définition de la variable est juste pour la commande de droite : sudo n'est rien d'autre qu'une surcouche à sh qui permet au sh de se lancer dans un autre env.
Ce que je veux dire par là, c'est que pour sudo, il n'a qu'un seul paramètre, toute la ligne (ou jusqu'au ; )

Voir 40 message(s) de cette discussion en une page