sudo: source: commande introuvable

40

J'ai mis à jour certains des profils par défaut de bash, et j'ai vu dans les tutoriels que je pouvais recharger le nouveau profil avec les nouveaux paramètres d'environnement en utilisant:

source /etc/bash.bashrc

La seule chose est - les nouvelles variables d'environnement étaient uniquement disponibles 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 je suis retourné.

Lorsque j'essaie d'utiliser:

sudo source /etc/bash.bashrc

J'ai 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 référençaient les variables. J'ai découvert que même s'ils pouvaient accéder directement aux variables lorsque j'appelais les scripts directement (même si cela créait un problème ultérieur avec la création de répertoires car je devais être root), appeler les scripts d'installation avec sudo ne le serait pas.

Je l'ai prouvé en testant avec ces commandes simples:

echo $ENV_VARIABLE
sudo echo $ENV_VARIABLE

Le premier produirait la valeur de la variable, mais le second n’a rien généré.

    
posée HorusKol 10.01.2011 - 23:25
la source

6 réponses

52

Le problème est que source est une commande intégrée à bash (pas un programme - comme ls ou grep ). Je pense qu'une approche consiste à vous connecter en tant que root, puis à exécuter la commande source.

sudo -s
source /etc/bash.bashrc
    
réponse donnée Marcos Roriz Junior 10.01.2011 - 23:31
la source
10

Le problème n'est pas que source est une commande intégrée au shell. Le fait que ce soit est ce qui vous lance réellement l'erreur command not found , 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 ça: Chaque fois qu'un nouveau processus est lancé, si rien ne se produit, il hérite de l'environnement de son parent. De ce fait, l'utilisation d'un sous-shell (par exemple, en tapant bash dans une instance de bash) et en regardant la sortie de env devrait donner des résultats similaires à ceux de son parent.

Cependant, en raison du fonctionnement de sudo (comme indiqué dans sa page de manuel), sudo tente de supprimer l’environnement de l’utilisateur et de créer un environnement "par défaut" pour l’utilisateur supplantant, de sorte que la commande run soit exécutée comme si l’utilisateur qui l’avait appelé était l’utilisateur appelant (qui est le comportement attendu), et donc exécuter nautilus comme sudo nautilus devrait ouvrir un dossier dans le dossier /root , et non /home/yourusername .

Donc:

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

Pour transmettre des variables d’environnement, vous pouvez soit dire à sudo de préserver l’environnement (via le commutateur -E et disposer des autorisations appropriées dans votre fichier sudoers) et / ou le définir pour la commande sudo VAR1=VALUE1 VAR2=VALUE2 command .

    
réponse donnée ssice 18.11.2013 - 20:28
la source
2

Comme Marcos dit , votre problème principal est que source est une commande intégrée au shell qui n'affecte que le processus shell dans lequel elle est exécutée.

La solution simple est de simplement lancer un nouveau shell en tant que root, et bash lira automatiquement /etc/bash.bashrc au démarrage. C'est aussi simple que de dire

sudo bash
    
réponse donnée poolie 11.01.2011 - 00:03
la source
2

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

    
réponse donnée psusi 11.01.2011 - 03:55
la source
0

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

Vous pouvez le vérifier en localisant le chemin d'accès 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 du 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. Ainsi, la commande d'erreur est introuvable.

Vous pouvez demander à sudo d’utiliser le PATH de l’utilisateur actuel lors de l’appel d’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.

Veuillez vous référer à cette vidéo pour une solution pas à pas

    
réponse donnée Anonymous Platypus 08.03.2018 - 10:49
la source
-1

En utilisant bash substitution de processus , vous pouvez:

source <(sudo cat /etc/bash.bashrc)
    
réponse donnée TomDotTom 30.07.2018 - 18:32
la source

Lire d'autres questions sur les étiquettes