Cette réponse porte principalement sur l'ordre dans lequel les variables d'environnement comme PATH
sont attribués lorsqu'ils sont spécifiés dans différents fichiers de configuration. J'aborde également l'endroit où vous devriez habituellement les définir, mais la liste ci-dessous ne liste pas les fichiers dans l'ordre dans lequel vous devriez envisager de les utiliser. Pour des informations générales sur la configuration de PATH
et d'autres variables d'environnement dans Ubuntu, je recommande également la lecture de Variables d'environnement et les autres réponses à cette question.
L'endroit préféré pour mettre PATH
dépend de quels utilisateurs vous devez le définir pour et quand et comment que vous voulez qu'il soit défini. Une partie de votre décision sera de savoir si vous voulez qu'une variable d'environnement soit définie pour tous les utilisateurs ou sur une base par utilisateur. Si vous n'êtes pas sûr, je vous recommande de la définir pour un seul utilisateur (par exemple, votre compte) plutôt que pour l'ensemble du système.
Comme AlexP dit le PATH
aura la valeur qu'elle avait le plus récemment attribué . En pratique, le plus du temps que vous avez fixé PATH
vous incluez le vieux valeur de PATH
dans la nouvelle valeur, de sorte que les entrées précédentes sont conservées.
Ainsi, dans la pratique, lorsque PATH
est défini à partir de plusieurs fichiers, il contient généralement les entrées données dans tous les fichiers. Mais cela n'arrive que parce que tous les fichiers qui le définissent, à l'exception du premier, font généralement référence au fichier PATH
la variable elle-même, en faisant en sorte que son ancienne valeur soit incluse dans la nouvelle.
Par conséquent, vous demandez en fait l'ordre dans lequel PATH
les paramètres des différents fichiers prennent effet.
Emplacements communs et polyvalents pour définir PATH
sont énumérés ci-dessous dans l'ordre dans lequel ils prennent effet lorsqu'un utilisateur se connecte, no dans l'ordre dans lequel vous envisagez généralement de les utiliser . Chacun des lieux énumérés ci-dessous est un choix raisonnable pour la mise en place PATH
sur un peu de situations mais seuls quelques-uns sont de bons choix la plupart du temps.
Dans la liste ci-dessous, vous verrez des noms de répertoire tels que ~/.profile
. Au cas où vous ne seriez pas familier avec le concept de expansion du tilde , ~/
fait référence au répertoire personnel de l'utilisateur actuel. J'utilise principalement cette syntaxe pour des raisons de compacité. Elle est supportée dans Shell Shell, mais no dans les fichiers de configuration de PAM.
1. Pour tous les utilisateurs : /etc/environment
PAM sur Ubuntu, les variables d'environnement listées dans /etc/environment
à définir, si ce fichier existe, ce qui est le cas par défaut. C'est ainsi que les variables d'environnement sont le plus souvent définies pour tous les utilisateurs.
$ 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 todo plutôt que votre seul compte d'utilisateur, alors modifier ce fichier est probablement votre meilleur choix. Je recommande de le sauvegarder d'abord. Une façon de sauvegarder ce fichier est d'exécuter :
sudo cp /etc/environment /etc/environment.orig
El .orig
n'est pas spécifiquement requise - vous pouvez donner au fichier de sauvegarde un nom qui ne prête pas à confusion ou qui est déjà utilisé. (En outre .orig
, .old
, .backup
y .bak
sont courantes).
Vous pouvez éditer ce fichier de la même manière que vous pouvez éditer n'importe quel autre fichier en tant qu'utilisateur root ( sudoedit /etc/enviromnment
, sudo nano -w /etc/environment
, gksudo gedit /etc/environment
etc.)
/etc/environment
ne supporte pas l'inclusion automatique de l'ancienne valeur d'une variable. Mais cela n'est généralement pas nécessaire, puisque la plupart du temps, vous définissez une variable d'environnement pour tous les utilisateurs en éditant le fichier /etc/environment
vous voudriez que ce soit sa valeur initiale lorsque l'utilisateur se connecte, de toute façon. L'utilisateur peut ensuite la modifier comme il le souhaite. En général, 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 pour tous les utilisateurs à partir de /etc/security/pam_env.conf
spécifié avec la même syntaxe que celle utilisée dans le cadre de l'option "par utilisateur". ~/.pam_environment
(voir ci-dessous).
Lorsque la même variable d'environnement est définie dans les deux /etc/environment
y /etc/security/pam_env.conf
la valeur dans pam_env.conf
est utilisé -- même si cette valeur est spécifiée en tant que DEFAULT
plutôt que OVERRIDE
.
Cependant, lorsque vous remplacez une ligne dans environment
avec un dans pam_env.conf
vous pouvez inclure le contenu de la valeur remplacée. Voir la section ci-dessous sur .pam_environment
pour plus de détails (puisqu'il utilise la même syntaxe).
Il n'est généralement pas nécessaire d'éditer pam_env.conf
y vous devez être très prudent si vous le faites puisque a malformé empêche généralement tous les comptes d'utilisateurs normaux de se connecter ! Par exemple, la ligne par défaut pam_env.conf
contient les lignes :
#PATH DEFAULT=${HOME}/bin:/usr/local/bin:/bin\
#:/usr/bin:/usr/local/bin/X11:/usr/bin/X11
Ceci est présenté comme un exemple parmi d'autres. Il illustre notamment la manière de répartir une affectation sur plusieurs lignes à l'aide de la fonction \
. Supposons que vous ayez décommenté la première ligne, mais que vous ayez oublié 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 faites pas ça !
J'ai testé cela moi-même par accident, et cela a empêché tous les utilisateurs de se connecter avec succès. Pour le réparer, j'ai dû démarrer en mode de récupération et le changer à nouveau. (Heureusement, j'ai fait cela sur une machine virtuelle que j'utilise uniquement pour tester des choses, de sorte que cela ne m'a causé aucun problème).
3. Pour un utilisateur : .pam_environment
dans le répertoire personnel de l'utilisateur
L'une des façons de définir une variable d'environnement pour un seul utilisateur est de modifier (ou de créer) le fichier .pam_environment
dans leur répertoire personnel. Les valeurs définies dans ce fichier remplacent celles définies dans le fichier global /etc/environment
fichier.
.pam_environment
ne fait pas partie du squelette de fichiers qui est copié dans le dossier personnel d'un utilisateur lors de la création initiale de son compte. Toutefois, si vous créez ce fichier dans votre répertoire personnel, vous pouvez l'utiliser pour définir des variables d'environnement telles que PATH
. Contrairement à /etc/environment
(mais comme /etc/security/pam_env.conf
), la valeur par utilisateur .pam_environment
prennent en charge l'expansion de l'ancienne valeur d'une variable d'environnement en une nouvelle. Ce ne sont pas des Shell Shell, cependant, et vous devez utiliser une syntaxe spéciale pour y parvenir, qui diffère quelque peu de la syntaxe que vous utiliseriez dans un fichier tel que .profile
.
Par exemple, si vous aviez un bin2
dans votre répertoire d'origine que vous vouliez ajouter à la fin du fichier PATH
vous pouvez le faire en ajoutant cette ligne à l'adresse suivante .pam_environment
:
PATH DEFAULT=${PATH}:/home/@{PAM_USER}/bin2
Voir le site ~/.pam_environment
sous-section de Variables d'environnement (dont l'exemple ci-dessus est étroitement adapté), man pam_env
y man pam_env.conf
pour plus de détails.
Bien que cette méthode ait été autrefois présentée comme la méthode préférée des utilisateurs d'Ubuntu pour modifier ou ajouter des variables d'environnement, elle est toujours considérée comme un choix raisonnable et acceptable, vous devez faire attention lorsque vous éditez .pam_environment
. Comme les modifications apportées au système /etc/security/pam_env.conf
(voir plus haut), une ligne malformée dans le code d'accès d'un utilisateur. .pam_environment
empêchera les connexions de réussir. (J'ai testé cela - volontairement cette fois.) Pour plus d'informations sur la manière dont les les recommandations ont évolué voir Gunnar Hjalmarsson 's commentaires en dessous de y este ubuntu-devel
discussion .
Une telle erreur est beaucoup moins grave, en général qu'une ligne malformée dans pam_env.conf
car elle ne concerne qu'un seul utilisateur. Cependant, dans le cas d'un système Ubuntu de bureau avec un seul compte d'utilisateur qui autorise les connexions, une telle erreur lors de l'édition de l'application .pam_environment
sera tout aussi mauvais qu'une erreur d'édition pam_env.conf
-- Si vous n'êtes pas déjà connecté, vous ne pourrez pas réparer le problème sans démarrer en mode de récupération (ou à partir d'une clé USB active, etc.).
(Si vous avez d'autres comptes d'utilisateur, vous pouvez vous connecter en tant qu'autre utilisateur et résoudre le problème. Même s'il ne s'agit pas d'un administrateur et qu'il ne peut pas sudo
à la racine, ils peuvent toujours exécuter su _your-account_
et vous serez invité à saisir votre (et non leur) mot de passe. Le site invité ne peut cependant pas le faire, puisqu'il lui est interdit d'utiliser les services de la su
pour prendre l'identité d'un autre utilisateur).
4. Pour tous les utilisateurs : /etc/profile
et les fichiers à l'intérieur /etc/profile.d/
Les shells compatibles avec Bourne (y compris bash
(l'utilisateur par défaut Shell dans Ubuntu) exécutez les commandes suivantes /etc/profile
lorsqu'il est invoqué comme un Shell de connexion.
Ubuntu /etc/profile
se termine 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
Cela fait en sorte que les commandes de n'importe quel fichier dans le fichier /etc/profile.d/
dont le nom se termine par .sh
à exécuter également.
La plupart des gestionnaires d'affichage provoquent les commandes dans /etc/profile
(et donc des fichiers dans /etc/profile.d
) à exécuter pour les connexions graphiques également. Cependant, Ce n'est pas le cas de tous, et c'est un argument de poids en faveur de l'utilisation des installations fournies par PAM au lieu de celles fournies par l'entreprise. (voir ci-dessus) -- à moins qu'il n'y ait jamais de connexions graphiques sur ce système, ce qui pourrait être le cas, par exemple, s'il s'agit d'un serveur sans interface graphique installée.
Il est traditionnel de définir des variables d'environnement pour l'ensemble du système dans le fichier /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 le définir pour tous les utilisateurs, il est probablement préférable de créer un nouveau fichier dans le dossier de l'utilisateur. /etc/profile.d/
que d'éditer /etc/profile
même. L'une des raisons est que, lors d'une mise à jour d'Ubuntu, il peut y avoir une nouvelle valeur par défaut. /etc/profile
fichier. Selon la façon dont vous effectuez la mise à niveau, soit l'ancien fichier (avec vos modifications) sera conservé, en renonçant à ce fichier de configuration mis à jour, soit vous serez invité à gérer la situation.
Lorsque la même variable d'environnement est définie dans les deux /etc/profile
et un ou plusieurs fichiers dans /etc/profile.d
lequel est exécuté en dernier ? Cela dépend si les commandes dans /etc/profile
qui les définissent apparaissent avant ou après les fichiers dans profile.d
ont été trouvés (par le code que j'ai cité ci-dessus). Les commandes dans /etc/profile
sont exécutées dans l'ordre où elles apparaissent.
/etc/profile
est un Shell Shell, et sa syntaxe est no le même que celui des fichiers de configuration PAM discutés ci-dessus . Sa syntaxe est la même que celle de l'option "par utilisateur". ~/.profile
(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 pas utiliser la fonction /etc/environment
o /etc/security/pam_env.conf
pour le faire. Il s'agit peut-être de la principale situation où il est préférable d'utiliser /etc/profile
o /etc/profile.d/
à la place.
5. Pour un utilisateur : .bash_profile
dans le répertoire personnel de l'utilisateur
Si un utilisateur a ~/.bash_profile
bash l'utilise à la place de ~/.profile
o ~/.bash_login
(voir ci-dessous). En général, vous ne devriez pas avoir de .bash_profile
dans votre répertoire personnel.
Si vous le faites, il doit généralement contenir une commande de source ~/.profile
(par exemple, . "$HOME/.profile"
). Sinon, le contenu du fichier .profile
ne sont pas exécutés du tout.
6. Pour un utilisateur : .bash_login
dans le répertoire personnel de l'utilisateur
Si un utilisateur a ~/.bash_login
bash l'utilise à la place de ~/.profile
(voir ci-dessous), sauf si ~/.bash_profile
existe, auquel cas aucun des autres ne sera utilisé à moins qu'il ne provienne de `~/.bash_login.
Comme avec .bash_profile
vous ne devriez généralement pas avoir de .bash_login
dans votre répertoire personnel.
7. Pour un utilisateur : .profile
dans le répertoire personnel de l'utilisateur.
Lorsqu'un Shell de style Bourne est exécuté en tant que Shell de connexion, il exécute les commandes dans /etc/profile
(qui comprend généralement des commandes qui provoquent les commandes dans les fichiers de la section /etc/profile.d/
à exécuter - voir ci-dessus). Après cela, il exécute les commandes dans .profile
dans le répertoire personnel de l'utilisateur. Ce fichier est distinct pour chaque utilisateur. (Bash exécute en fait .bash_profile
o .bash_login
à la place s'ils existent -- mais, pour les utilisateurs d'un système Ubuntu, ces fichiers devraient rarement exister ou existent effectivement. Pour plus de détails, voir ci-dessus et 6.2 Fichiers de démarrage de Bash en le manuel Bash .)
~/.profile
est donc le principal endroit où l'utilisateur peut placer les commandes qui s'exécutent lorsqu'il se connecte. C'est l'endroit traditionnel où l'on place ses PATH
mais comme Ubuntu a le module pam_env et supporte ~/.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, mais la plupart le font. C'est une raison de préférer ~/.pam_environment
pour définir les variables d'environnement (bien qu'on puisse préférer /etc/environment
a /etc/profile
).
Vous pouvez développer les variables d'environnement, notamment PATH
lui-même, lorsque vous définissez PATH
en .pam_environment
(voir ci-dessus). Toutefois, si vous devez définir PATH
d'une manière plus sophistiquée, vous devrez peut-être utiliser votre .profile
à la place. En particulier, si vous voulez vérifier si un répertoire existe à chaque fois qu'un utilisateur se connecte et seulement l'ajouter à PATH
si c'est le cas, alors vous ne pourrez pas utiliser votre .pam_environment
pour ajouter ce répertoire à votre PATH
.
Par exemple, la valeur par défaut par utilisateur .profile
sur Ubuntu utilisé pour se terminer par :
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
Voir Gunnar Hjalmarsson 's commentaire en Réponse de Byte Commander pour les détails.
Cela vérifie si vous avez un bin
dans le sous-répertoire de votre répertoire personnel. Si c'est le cas, il ajoute ce sous-répertoire au début de votre fichier PATH
.
Cette liste omet certaines possibilités.
Il existe d'autres façons de définir les variables d'environnement lorsque les utilisateurs se connectent, qui dépendent davantage du type de connexion. Par exemple, vous pouvez parfois avoir des variables d'environnement qui sont définies uniquement pour les connexions graphiques ou pour les connexions distantes basées sur SSH. La liste ci-dessus ne couvre pas ces cas.
J'ai laissé de côté quelques fichiers où les gens définissent parfois des variables d'environnement, telles que ~/.bashrc
y /etc/bash.bashrc
parce qu'il n'est généralement pas recommandé de les placer dans des endroits où il est possible d'en faire autant. PATH
et il est rare que vous deviez réellement les utiliser dans ce but. Si vous utilisez ces fichiers pour ajouter des répertoires à PATH
alors ils seront parfois ajoutés plusieurs fois, ce qui est très déroutant lorsque l'on examine $PATH
. (Dans des cas extrêmes, cela peut ralentir les choses, mais en général, il s'agit simplement de garder tout propre et compréhensible).
Desde bash
est le Shell de connexion par défaut d'Ubuntu pour les utilisateurs, et la plupart des utilisateurs l'utilisent ou un autre Shell compatible POSIX, j'ai omis les informations sur la façon dont les variables d'environnement sont définies dans d'autres shells de style non-Bourne, tels que tcsh
.