sudo: source: commande introuvable


54

J'ai mis à jour une partie du profil par défaut pour bash et j'ai vu dans les tutoriels que je suivais que je pouvais recharger le nouveau profil avec les nouveaux paramètres d'environnement en utilisant:

source /etc/bash.bashrc

La seule chose à faire est que les nouvelles variables d'environnement n'étaient disponibles que pour mon utilisateur actuel et ont été ignorées lorsque j'ai utilisé sudo. Ils ne sont devenus disponibles pour sudo que lorsque j'ai fermé ma session de terminal et que j'ai rejoint le groupe.

Quand j'essaye d'utiliser:

sudo source /etc/bash.bashrc

Je reçois l'erreur:

sudo: source: command not found

Existe-t-il un moyen simple de charger les nouveaux paramètres de profil bash pour sudo sans avoir à fermer le terminal et à redémarrer?

- Au départ, j'utilisais des scripts d'installation qui faisaient référence aux variables. J'ai constaté qu'alors qu'ils pouvaient accéder aux variables lorsque j'appelais les scripts directement (bien que cela poserait un problème de création de répertoires car je devais être root), appeler les scripts d'installation à l'aide de sudo ne le ferait pas.

J'ai prouvé cela en testant avec ces commandes simples:

echo $ENV_VARIABLE
sudo echo $ENV_VARIABLE

Le premier afficherait la valeur de la variable, mais le second ne produirait rien.


Comment avez-vous essayé d'utiliser les variables de sudo? Veuillez noter que si vous utilisez "sudo command $ variable", cela remplacera la variable de votre shell et non de l'environnement de sudo.
João Pinto

Réponses:


72

Le problème est qu’il sources’agit d’une commande intégrée de bash (et non d’un programme - comme lsou grep). Je pense qu'une solution consiste à se connecter en tant que root, puis à exécuter la commande source.

sudo -s
source /etc/bash.bashrc

3
Vous avez raison de dire que le problème est qu’il sources’agit d’un shell intégré. sudo suest une sorte de façon bizarre de le dire - mieux vaut juste dire sudo -squelle est la façon dont sudo dit de "démarrer un shell comme cet utilisateur". Votre version en une ligne ne fonctionnera pas car chacune des commandes est exécutée par le shell de l'utilisateur principal dans un sous-processus distinct.
poolie

1
Droite. De plus, BASH lit / etc / bashrc au moment de la connexion. Donc, vous pouvez aussi bien utiliser 'su' avec les commutateurs -, -l ou --login pour obtenir l'environnement de cet utilisateur: 'sudo su -' devienne root ou 'su - $ username' pour devenir un autre utilisateur.

L'exemple "une ligne" ne fonctionnera pas car suun nouveau shell est lancé et "source" est exécuté uniquement après sa fin. Le premier exemple ne fonctionne que si la deuxième ligne est utilisée à l' intérieur du shell root.
Loevborg

sudo -sn'est pas meilleur que sudo su. Cela n'aura aucun effet de toute façon.
Loevborg

1
sudo -sLe démarrage d’un shell a le même effet, mais il me semble inélégant d’empiler deux commandes "devenez un autre utilisateur" quand on le ferait.
poolie

14

Le problème n'est pas qu'il sources'agisse d'une commande intégrée au shell. Le fait que ce soit la cause de l' command not founderreur, mais cela ne signifie pas que cela fonctionnerait si c'était le cas.

Le problème réel est le fonctionnement des variables d’environnement. Et ils fonctionnent comme ceci: chaque fois qu’un nouveau processus est démarré, si rien ne se passe, il hérite de l’environnement de son parent. Pour cette raison, utiliser un sous-shell (par exemple, taper bashdans une instance bash) et consulter le résultat de envdevrait donner des résultats similaires à ceux de son parent.

Cependant, en raison de la manière dont il sudofonctionne (comme indiqué dans sa page de manuel), sudo tente de supprimer l'environnement de l'utilisateur et crée un environnement "par défaut" pour l'utilisateur supplantant, afin que l'exécution de la commande soit exécutée comme si l'utilisateur qui l'avait invoqué avait été l'utilisateur appelant (ce qui est le comportement attendu), et donc exécuter Nautilus comme sudo nautilusdevrait ouvrir un dossier dans le /rootdossier, et non /home/yourusername.

Alors:

Faire quelque chose comme sudo source script.shet puis sudo command, même si cela fonctionnait, cela ne réussirait pas à définir une variable à plus tard sudo command.

Afin de transmettre les variables d'environnement, vous pouvez demander à sudo de préserver l'environnement (via le -Ecommutateur; disposer des autorisations appropriées dans votre fichier sudoers) et / ou de le définir pour la commande sudo VAR1=VALUE1 VAR2=VALUE2 command.


4

En utilisant la substitution de processus bash , vous pouvez faire:

source <(sudo cat /etc/bash.bashrc)

1
Comment cela aiderait-il à démarrer un shell racine avec les nouveaux paramètres, ce que l’OP cherche à faire?
Muru

1
L'OP demandait en fait comment "... recharger le nouveau profil ..." à partir d'un shell qui doit utiliser sudopour accéder au profil. Ce qui précède permet d'importer le profil tout en évitant le sudo: source: command not foundproblème mentionné.
TomDotTom

"La seule chose à faire est que les nouvelles variables d'environnement n'étaient disponibles que pour mon utilisateur actuel - et ont été ignorées lorsque j'ai utilisé sudo."
muru

3

Comme le dit Marcos , votre principal problème ici est qu’il sources’agit d’une commande intégrée du shell qui affecte uniquement le processus du shell dans lequel il s’exécute.

La solution la plus simple consiste à démarrer un nouveau shell en tant qu’utilisateur root et bash lira automatiquement au /etc/bash.bashrcdémarrage. C'est aussi simple que de simplement dire

sudo bash

2

La fermeture et la réouverture du terminal ne devraient pas changer les choses. Par défaut, sudo supprime l'environnement. Pour le désactiver, ajoutez -E à sudo.


2

L'erreur se produit car le binaire que vous essayez d'appeler à partir de la ligne de commande ne constitue qu'une partie de la variable PATH de l'utilisateur actuel, mais pas une partie de PATH de l'utilisateur root.

Vous pouvez le vérifier en localisant le chemin du fichier binaire auquel vous tentez d'accéder. Dans mon cas, j'essayais d'appeler "bettercap-ng". Alors j'ai couru,

$ which bettercap-ng
/home/user/work/bin/bettercap`

J'ai vérifié si cet emplacement faisait partie de PATH de mon utilisateur root.

$ sudo env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

Donc, sudo ne peut pas trouver le binaire que j'essaie d'appeler depuis la ligne de commande. Par conséquent, renvoie la commande d'erreur non trouvée.

Vous pouvez demander à sudo d'utiliser le PATH de l'utilisateur actuel pour appeler un binaire comme ci-dessous.

sudo -E env "PATH=$PATH" [command] [arguments]

En fait, on peut en faire un alias:

alias mysudo='sudo -E env "PATH=$PATH"'

Il est également possible de nommer l'alias lui-même sudo, en remplacement du sudo d'origine.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.