Cette réponse concerne principalement l’ordre dans lequel les variables d’environnement PATHsont assignées lorsqu’elles sont spécifiées dans différents fichiers de configuration. Je couvre également les domaines dans lesquels vous devez généralement les configurer, mais la liste ci-dessous ne répertorie pas les fichiers dans l’ordre dans lequel vous devriez envisager de les utiliser. Pour des informations générales sur la configuration PATHet les autres variables d'environnement dans Ubuntu, je vous recommande également de lire les variables d' environnement et les autres réponses à cette question.
L'emplacement préféré à définir PATHdépend des utilisateurs pour lesquels vous devez le définir, quand et comment vous souhaitez le configurer. Une partie de votre décision sera de décider si vous souhaitez définir une variable d’environnement pour tous les utilisateurs ou pour chaque utilisateur. Si vous n'êtes pas sûr, je vous recommande de le configurer pour un seul utilisateur (par exemple, votre compte) plutôt que pour l'ensemble du système.
Comme AlexP le dit , la PATHvariable d'environnement aura la valeur qui lui a été assignée le plus récemment . En pratique, la plupart du temps que vous définissez PATH, vous incluez l' ancienne valeur de PATHdans la nouvelle valeur, afin que les entrées précédentes soient conservées.
Ainsi, en pratique, lorsqu'il PATHest défini à partir de plusieurs fichiers, il contient généralement les entrées indiquées dans tous les fichiers. Mais cela ne se produit que parce que tous les fichiers qui la définissent, à l’exception du premier, référencent généralement la PATHvariable elle-même, ce qui entraîne l’inclusion de l’ancienne valeur dans la nouvelle.
Par conséquent, vous demandez effectivement l'ordre dans lequel les PATHparamètres de divers fichiers prennent effet.
Les emplacements communs à usage général à définir PATHsont répertoriés ci-dessous dans l'ordre dans lequel ils prennent effet lorsqu'un utilisateur se connecte, et non dans l'ordre dans lequel vous devriez normalement envisager de les utiliser . Chacun des endroits énumérés ci-dessous est un choix raisonnable pour le réglage PATH dans certaines situations , mais seuls quelques-uns sont de bons choix la plupart du temps.
Dans la liste ci-dessous, vous verrez des noms de répertoires tels que ~/.profile. Si vous ne connaissez pas le développement de tilde , ~/fait référence au répertoire de base de l'utilisateur actuel. J'utilise principalement cette syntaxe pour la compacité. Il est pris en charge dans les scripts shell, mais pas dans les fichiers de configuration PAM.
1. Pour tous les utilisateurs: /etc/environment
PAM sur Ubuntu permet /etc/environmentde définir les variables d’environnement répertoriées dans , si ce fichier existe, ce qu’il fait par défaut. C'est ainsi que les variables d'environnement pour tous les utilisateurs sont le plus souvent définies.
$ cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
Si vous devez définir des variables d'environnement pour tous les comptes d'utilisateur, et pas uniquement pour votre compte d'utilisateur, la modification de ce fichier est probablement votre meilleur choix. Je recommande de le sauvegarder en premier. Une façon de sauvegarder ce fichier est de lancer:
sudo cp /etc/environment /etc/environment.orig
L' .origextension n'est pas spécifiquement requise - vous pouvez nommer le fichier de sauvegarde avec un nom qui ne soit pas source de confusion ou qui est déjà utilisé. ( D' ailleurs .orig, .old, .backupet .baksont communs.)
Vous pouvez modifier ce fichier dans l' une des façons dont vous pouvez modifier tout autre fichier en tant qu'utilisateur root ( sudoedit /etc/enviromnment, sudo nano -w /etc/environment, gksudo gedit /etc/environment, etc.)
/etc/environmentne prend pas en charge l'inclusion automatique de l'ancienne valeur d'une variable. Mais cela est généralement inutile, car la plupart du temps, vous définissez une variable d'environnement pour tous les utilisateurs en la modifiant /etc/environment, vous souhaitez que ce soit sa valeur initiale lorsque l'utilisateur se connecte, quoi qu'il en soit. L'utilisateur peut alors le changer à sa guise. En règle générale, il est bon que les utilisateurs puissent le faire.
2. Pour tous les utilisateurs: /etc/security/pam_env.conf
PAM lit les variables d'environnement de tous les utilisateurs de /etc/security/pam_env.conf, spécifiées avec la même syntaxe que celle utilisée dans les ~/.pam_environmentfichiers par utilisateur (voir ci-dessous).
Lorsque la même variable d'environnement est définie dans les deux /etc/environmentet /etc/security/pam_env.conf, la valeur dans pam_env.confest utilisée - même si cette valeur est spécifiée comme DEFAULTplutôt que OVERRIDE.
Toutefois, lorsque vous SUPERSEDE une ligne environmentavec celui pam_env.conf, vous pouvez inclure le contenu de la valeur remplacée. Voir la section ci-dessous .pam_environmentpour plus de détails (car il utilise la même syntaxe).
Il n’est généralement pas nécessaire d’éditer pam_env.confet vous devez faire très attention , car une ligne mal formée empêchera généralement tous les comptes d’utilisateurs normaux de se connecter! Par exemple, la valeur par défaut pam_env.confcontient les lignes:
#PATH DEFAULT=${HOME}/bin:/usr/local/bin:/bin\
#:/usr/bin:/usr/local/bin/X11:/usr/bin/X11
Ceci est présenté comme l'un de plusieurs exemples. L’une des choses illustrées est la façon de fractionner une affectation sur plusieurs lignes \. Supposons que vous ne décommentiez que la première ligne mais oubliez de décommenter la deuxième ligne:
PATH DEFAULT=${HOME}/bin:/usr/local/bin:/bin\
#:/usr/bin:/usr/local/bin/X11:/usr/bin/X11
Ne fais pas ça!
Je viens de le tester moi-même par accident, ce qui a empêché tout utilisateur de se connecter avec succès. Pour résoudre ce problème, je devais démarrer en mode de récupération et le rétablir. (Heureusement, je l'ai fait sur une machine virtuelle que je n'utilise que pour tester des choses, cela ne m'a donc pas posé de problèmes.)
3. Pour un utilisateur: .pam_environmentdans le répertoire de base de l'utilisateur
L'un des moyens de définir une variable d'environnement pour un seul utilisateur consiste à modifier (ou créer) cet utilisateur .pam_environmentdans son répertoire de base. Les valeurs définies dans ce fichier remplacent celles définies dans le /etc/environmentfichier global .
.pam_environmentne fait pas partie du squelette de fichiers copié dans le dossier de départ de l'utilisateur lors de la création initiale du compte d'utilisateur. Toutefois, si vous créez ce fichier dans votre répertoire de base, vous pouvez l’utiliser pour définir des variables d’environnement telles que PATH. Contrairement à /etc/environment(mais similaire /etc/security/pam_env.conf), les .pam_environmentfichiers par utilisateur prennent en charge l'extension de l'ancienne valeur d'une variable d'environnement en une nouvelle. Cependant, ce ne sont pas des scripts de shell et vous devez utiliser une syntaxe spéciale pour ce faire, qui diffère quelque peu de la syntaxe que vous utiliseriez dans un fichier du type .profile.
Par exemple, si vous bin2souhaitiez ajouter un répertoire à la fin de votre répertoire de base PATH, vous pouvez le faire en ajoutant cette ligne à .pam_environment:
PATH DEFAULT=${PATH}:/home/@{PAM_USER}/bin2
Voir le ~/.pam_environmentparagraphe de EnvironmentVariables (dont l'exemple ci - dessus est étroitement adapté), man pam_envet man pam_env.confpour plus de détails.
Bien que cela ait déjà été présenté comme le moyen privilégié par les utilisateurs d’Ubuntu de modifier ou d’ajouter des variables d’environnement et qu’il soit toujours considéré comme un choix raisonnable et acceptable, vous devez être prudent lors de la modification.pam_environment . Comme les modifications apportées à l'ensemble du système /etc/security/pam_env.conf(voir ci-dessus), une ligne mal formée dans le .pam_environmentfichier d' un utilisateur empêchera les connexions de réussir. (Je l' ai testé -. Sur le but cette fois -ci ) Pour plus d' informations sur la façon dont les recommandations ont évolué , voir Gunnar Hjalmarsson de commentaires ci - dessous et cette ubuntu-develdiscussion .
Une telle erreur est beaucoup moins grave, en général , qu'une ligne malformé pam_env.conf, car elle affecte un seul utilisateur. Cependant, dans le cas d'un système Ubuntu de bureau avec un seul compte utilisateur permettant les connexions, une telle erreur lors de l'édition .pam_environmentsera aussi grave qu'une édition erronée pam_env.conf- si vous n'êtes pas déjà connecté, vous ne pourrez pas pour le réparer sans démarrer en mode de récupération (ou à partir d'un live USB, etc.).
(Si vous avez d'autres comptes d'utilisateurs, vous pouvez vous connecter en tant qu'autre utilisateur et résoudre le problème. Même s'ils ne sont pas administrateurs et ne peuvent pas sudoroot, ils peuvent toujours s'exécuter et être invités à entrer votre mot de passe (pas leur mot de passe). . l' invité cependant, compte, ne peut pas le faire, car il est interdit d'utiliser pour prendre l'identité d'un autre utilisateur.)su your-accountsu
4. Pour tous les utilisateurs: /etc/profileet les fichiers à l'intérieur/etc/profile.d/
Les shells compatibles Bourne (y compris bashle shell utilisateur par défaut dans Ubuntu) exécutent les commandes /etc/profilelorsqu'ils sont appelés en tant que shell de connexion.
Ubuntu se /etc/profile.dtermine par:
if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi
Ainsi, les commandes de tout fichier du /etc/profile.d/répertoire dont le nom se termine .shsont également exécutées.
La plupart des gestionnaires d’affichage demandent également l’exécution des commandes /etc/profile(et donc des fichiers /etc/profile.d) pour les connexions graphiques. Cependant, ce n’est pas le cas de tous et c’est un argument important en faveur de l’utilisation des fonctionnalités fournies par PAM (voir ci-dessus) - à moins qu’il n’y ait jamais de connexions graphiques à ce système, ce qui pourrait être le cas, par exemple, si c’est le cas. un serveur sans interface graphique installée.
Il est de tradition de définir des variables d'environnement à l'échelle du système /etc/profile, mais ce n'est souvent plus le meilleur choix. Si vous ne pouvez pas définir une variable d'environnement dans /etc/environment, et que vous devez la définir pour tous les utilisateurs, il est probablement préférable de créer un nouveau fichier /etc/profile.d/plutôt que de le modifier /etc/profilelui-même. Une des raisons est que, lors de la mise à niveau d’Ubuntu, il peut y avoir un nouveau /etc/profilefichier par défaut . En fonction de la manière dont vous effectuez la mise à niveau, l'ancien fichier (avec vos modifications) sera conservé, en laissant de côté ce fichier de configuration mis à jour, ou vous serez invité à gérer la situation.
Lorsque la même variable d'environnement est définie dans les deux /etc/profileet dans un ou plusieurs fichiers /etc/profile.d, quelle est la dernière exécution? Cela dépend si les commandes /etc/profilequi les définissent apparaissent avant ou après la profile.dsource des fichiers (d'après le code que j'ai cité plus haut). Les commandes dans /etc/profilesont exécutées dans l'ordre dans lequel elles apparaissent.
/etc/profileest un script shell et sa syntaxe n'est pas la même que celle des fichiers de configuration PAM décrits ci-dessus . Sa syntaxe est la même que celle du ~/.profilefichier par utilisateur (voir ci-dessous).
Si vous devez écrire du code qui décide d'ajouter ou non un répertoire particulier PATH(et de le faire pour tous les utilisateurs), vous ne pourrez /etc/environmentni l' utiliser ni /etc/security/pam_env.confle faire. C'est peut-être la situation principale où il vaut mieux utiliser /etc/profileou /etc/profile.d/plutôt.
5. Pour un utilisateur: .bash_profiledans le répertoire de base de l'utilisateur
Si un utilisateur en a ~/.bash_profile, bash l'utilise au lieu de ~/.profileou ~/.bash_login(voir ci-dessous). Vous ne devriez généralement pas en avoir .bash_profiledans votre répertoire personnel.
Si vous le faites, il devrait généralement contenir une commande à source ~/.profile(par exemple, . "$HOME/.profile"). Sinon, le contenu du .profilefichier par utilisateur n'est pas exécuté du tout.
6. Pour un utilisateur: .bash_logindans le répertoire de base de l'utilisateur
Si un utilisateur en a ~/.bash_login, bash l'utilise au lieu de ~/.profile(voir ci-dessous), sauf s'il en ~/.bash_profileexiste un. Dans ce cas, aucun des autres ne sera utilisé, à moins qu'il provienne de `~ / .bash_login.
Comme avec .bash_profile, vous ne devriez généralement pas avoir de .bash_loginfichier dans votre répertoire personnel.
7. Pour un utilisateur: .profiledans le répertoire de base de l'utilisateur.
Lorsqu'un shell de style Bourne est exécuté en tant que shell de connexion, il exécute les commandes /etc/profile(ce qui inclut généralement les commandes qui entraînent l' /etc/profile.d/exécution des commandes contenues dans les fichiers - voir ci-dessus). Après cela, il exécute les commandes .profiledans le répertoire de base de l'utilisateur. Ce fichier est séparé pour chaque utilisateur. (Bash s'exécute .bash_profileou .bash_loginremplace les fichiers s'ils existent, mais pour les utilisateurs d'un système Ubuntu, ces fichiers devraient rarement exister. Pour plus d'informations, voir ci-dessus et 6.2 Fichiers de démarrage Bash dans le manuel Bash .)
~/.profileest donc le lieu principal pour l'utilisateur pour mettre des commandes qui s'exécutent lorsqu'ils se connectent. C’est l’endroit traditionnel pour vous de définir votre PATH, mais comme Ubuntu a le module pam_env et qu’il prend en charge ~/.pam_environment, vous devriez envisager de l’utiliser.
Comme avec /etc/profile, tous les gestionnaires d'affichage n'exécutent pas ce fichier pour les connexions graphiques, bien que la plupart le fassent. Ceci est une raison de préférer ~/.pam_environmentpour la définition des variables d'environnement (autant que l' on peut préférer /etc/environmentà /etc/profile).
Vous pouvez étendre les variables d'environnement, y compris PATHlui - même, lorsque vous définissez PATHdans .pam_environment(voir ci - dessus). Toutefois, si vous devez définir PATHune méthode plus sophistiquée, vous devrez peut-être utiliser votre .profile. En particulier, si vous voulez vérifier si un répertoire existe chaque fois qu'un utilisateur se connecte et ne l'ajouter qu'à PATHsi c'est le cas, vous ne pourrez pas utiliser votre .pam_environmentfichier pour ajouter ce répertoire à votre PATH.
Par exemple, le .profilefichier par utilisateur sous Ubuntu par défaut se terminait par:
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
Voir le commentaire de Gunnar Hjalmarsson sur la réponse de Byte Commander pour plus de détails.
Ceci vérifie si vous avez un binsous - répertoire de votre répertoire personnel. Si tel est le cas, il ajoute ce sous-répertoire au début de votre PATH.
Cette liste omet certaines possibilités.
Les variables d’environnement définies lors de la connexion des utilisateurs dépendent davantage du type de connexion. Par exemple, vous pouvez parfois avoir des variables d'environnement définies uniquement pour les connexions graphiques ou uniquement pour les connexions distantes basées sur SSH. La liste ci-dessus ne couvre pas de tels cas.
J'ai omis quelques fichiers dans lesquels les utilisateurs définissent parfois des variables d'environnement, telles que ~/.bashrcet /etc/bash.bashrc, car ce ne sont généralement pas des emplacements recommandés PATHet il est rare que vous deviez les utiliser à cette fin. Si vous utilisez ces fichiers pour ajouter des répertoires PATH, ils seront parfois ajoutés plusieurs fois, ce qui peut être très déroutant lorsque vous examinez $PATH. (Dans des cas extrêmes, cela peut ralentir les choses, mais en général, il suffit de tout garder propre et compréhensible.)
Comme bashc'est le shell de connexion par défaut d'Ubuntu pour les utilisateurs, et que la plupart des utilisateurs l'utilisent ou un autre shell compatible POSIX, j'ai omis des informations sur la manière dont les variables d'environnement sont définies dans d'autres shells de style non Bourne tels que tcsh.