Discussion :

[papajoker]

bonjour

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.

[developpeurP00]

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

[developpeurP00]

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

[balkany]

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 :

Modifications to PATH take effect prior to searching for command.

sudo ne fonctionne manifestement pas comme ça.

[papajoker]

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

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) ...

[foetus]

Si je comprends bien ...

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

Je ne suis pas expert en Linux 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 (avec env ou carrément avec sh -c 'XXXX')

[Sve@r]

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

Donne leur l'URL de ce topic...

En déroulant le fil de discussion 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.

[disedorgue]

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 :

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

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 :

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

1
2
3
$ env --help
Utilisation*: env [OPTION]... [-] [NOM=VALEUR]... [COMMANDE [ARG]...]
Initialiser chaque NOM à VALEUR dans l'environnement et exécuter COMMANDE.

[balkany]

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

Code :

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

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.../#post11961400 ), mais elle ne le fait pas.

[disedorgue]

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

Code :

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

PATH=$PATH sudo commande

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

Code :

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

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 :

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

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

Code :

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

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)

[Sve@r]

Code :

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

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

Code :

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

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é.

[N_BaH]

ça peut être contourner avec --perserve-env[=LIST] ?

[Sve@r]

Pense pas.
En reprenant mon "toto.sh" copié dans mon bin, j'ai tenté...

Code :

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

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.

[N_BaH]

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.

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 !

[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é.

[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 ; )