web-dev-qa-db-fra.com

Définition de la variable PATH dans / etc / environment vs .profile

Où est le lieu préféré pour définir la variable PATH?

~/.profile ou /etc/environment?

Quel est le cas lorsque PATH est défini aux deux endroits? Le résultat final est-il une concaténation des deux valeurs définies à ces deux endroits?

environment-variablespaths
45
pkaramol

Résumé:

  • Si vous souhaitez ajouter un chemin (par exemple, /your/additional/path) à votre variable PATH pour votre utilisateur actuel uniquement et non pour tous les utilisateurs de votre ordinateur, vous le placez normalement à la fin de ~/.profile, comme dans l'un de ces deux exemples:

    PATH="/your/additional/path:$PATH"
PATH="$PATH:/your/additional/path"

    Notez que les priorités de chemin descendant de gauche à droite, le premier chemin a la priorité la plus élevée. Si vous ajoutez votre chemin à gauche de $PATH, il aura la priorité la plus élevée et les exécutables situés à cet emplacement remplaceront tous les autres. Si vous ajoutez votre chemin à droite, il aura la priorité la plus basse et les exécutables des autres emplacements seront préférés.

  • Toutefois, si vous devez définir cette variable d'environnement pour tous les utilisateurs, je ne recommanderais toujours pas de toucher /etc/environment mais de créer un fichier dont le nom se termine par .sh dans /etc/profile.d/. Le script /etc/profile et tous les scripts de /etc/profile.d sont l'équivalent global du ~/.profile personnel de chaque utilisateur et sont exécutés sous la forme de scripts Shell normaux par tous les shells lors de leur initialisation.

Plus de détail:

  • /etc/environment est un fichier de configuration à l'échelle du système, ce qui signifie qu'il est utilisé par tous les utilisateurs. Il appartient cependant à root. Vous devez donc être un utilisateur administrateur et utiliser Sudo pour le modifier.

  • ~/.profile est l'un des scripts d'initialisation de shell personnels de votre propre utilisateur. Chaque utilisateur en possède un et peut éditer son fichier sans en affecter les autres.

  • /etc/profile et /etc/profile.d/*.sh sont les scripts d'initialisation globaux équivalents à ~/.profile pour chaque utilisateur. Les scripts globaux sont exécutés avant les scripts spécifiques à l'utilisateur. et le /etc/profile principal exécute tous les scripts *.sh dans /etc/profile.d/ juste avant sa fermeture.

  • Le fichier /etc/environment contient normalement uniquement cette ligne:

    PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

    Il définit la variable PATH pour tous les utilisateurs du système sur cette valeur par défaut, qui ne doit pas être modifiée de manière majeure. Au moins, vous ne devriez supprimer aucun des chemins importants tels que /bin, /sbin, /usr/bin et /usr/sbin.

    Ce fichier est lu comme l'un des premiers fichiers de configuration par chaque shell de chaque utilisateur. Notez qu'il ne s'agit pas d'un script shell . C'est juste un fichier de configuration qui est analysé d'une manière ou d'une autre et qui ne peut contenir que des affectations de variables d'environnement!

  • Le fichier ~/.profile peut contenir beaucoup d'éléments. Par défaut, il contient, entre autres, une vérification de l'existence d'un répertoire ~/bin et l'ajoute à la variable PATH existante de l'utilisateur, comme ceci (dans les versions plus anciennes d'Ubuntu antérieures à 16.04 - les nouvelles versions l'ajoutent sans condition):

    # set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

    Vous voyez que l’ancienne valeur de PATH est réutilisée ici et que le nouveau chemin n’est ajouté qu’au début, au lieu de tout écraser. Lorsque vous souhaitez ajouter manuellement de nouveaux chemins, vous devez également toujours conserver l'ancienne valeur $PATH quelque part dans la nouvelle chaîne.

    Ce script d'initialisation est lu uniquement par les shells de l'utilisateur auquel il appartient, mais il existe une autre condition:

    # ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.

    Par conséquent, si vous utilisez le shell Bash par défaut, vous devez vous assurer que vous n'avez pas ~/.bash_profile ou ~/.bash_login si vous voulez que les modifications apportées à ~/.profile aient un effet pour votre utilisateur.

Pour une compréhension complète des variables d'environnement, voir: https://help.ubuntu.com/community/EnvironmentVariables

Question associée: différence entre les fichiers bash.bashrc et/etc/environment

56
Byte Commander

Cette réponse concerne principalement l'ordre dans lequel les variables d'environnement telles que PATHsont attribuées lorsqu'elles sont spécifiées dans des fichiers de configuration différents. 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 de PATHet d'autres variables d'environnement dans Ubuntu, je vous recommande également de lire EnvironmentVariables et les autres réponses à cette question .

L'emplacement privilégié pour définir PATHdépend de quels utilisateurs vous devez le définir pour et quand et comment ​​vous voulez qu'il soit défini. 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 (votre compte, par exemple) plutôt que pour l'ensemble du système.

Comme AlexP dit , la variable d'environnement PATHaura la valeur qu'elle était dernière affectation. En pratique, la plupart ​​au moment où vous avez défini PATHname__, vous incluez la old valeur de PATHdans la nouvelle valeur, de sorte que les entrées précédentes soient conservées.

Ainsi, en pratique, lorsque 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 le définissent, à l’exception du premier, font généralement référence à la variable PATHname__, ce qui entraîne l’inclusion de l’ancienne valeur dans la nouvelle.

Par conséquent, vous demandez effectivement l'ordre dans lequel les paramètres PATHde divers fichiers prennent effet.

Les emplacements courants à usage général pour définir PATHsont répertoriés ci-dessous dans l'ordre dans lequel ils prennent effet lorsqu'un utilisateur se connecte, not ​​dans l'ordre que vous devez généralement prendre en compte en les utilisant . Chacun des endroits énumérés ci-dessous est un choix raisonnable pour définir PATH dans certaines situations , mais seuls quelques-uns sont de bons choix. du temps.

Dans la liste ci-dessous, vous verrez des noms de répertoire tels que ~/.profile. Si vous ne connaissez pas 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 not ​​dans les fichiers de configuration PAM.

1. Pour tous les utilisateurs: /etc/environment

PAM sur Ubuntu permet de définir les variables d’environnement répertoriées dans /etc/environment, si ce fichier existe, ce qui est le cas 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 comptes d'utilisateurs, plutôt que simplement 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'extension .orig n'est pas spécifiquement requise - vous pouvez nommer le fichier de sauvegarde avec un nom qui ne crée pas de confusion ou qui est déjà utilisé. (Outre .orig, .old, .backup et .bak sont communs.)

Vous pouvez éditer ce fichier de différentes manières que vous le feriez en tant qu'utilisateur root (sudoedit /etc/enviromnment, Sudo nano -w /etc/environment, gksudo gedit /etc/environment, etc.).

/etc/environment ne prend pas en charge l'inclusion automatique de l'ancienne valeur d'une variable. Mais cela n’est généralement pas nécessaire, étant donné que la plupart du temps vous définissez une variable d’environnement pour tous les utilisateurs en modifiant /etc/environment, vous voudriez que ce soit sa valeur initiale lorsque l’utilisateur se connecte, de toute façon. 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 pour tous les utilisateurs à partir de /etc/security/pam_env.conf, spécifiées avec la même syntaxe que celle utilisée dans les fichiers ~/.pam_environment par utilisateur (voir ci-dessous).

Lorsque la même variable d'environnement est définie dans /etc/environment et /etc/security/pam_env.conf, la valeur dans pam_env.conf est utilisée, même si cette valeur est spécifiée sous la forme DEFAULTplutôt que OVERRIDEname__.

Toutefois, lorsque vous remplacez une ligne dans environmentpar une autre 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 de modifier pam_env.conf et , vous devez être très prudent si vous le faites , puisqu'un --- malformed empêchera généralement tout comptes d'utilisateur normaux de se connecter du tout! Par exemple, la valeur par défaut pam_env.conf contient les lignes suivantes:

#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 avec \. Supposons que vous ne décommentiez que la première ligne, mais que vous 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 faites pas ça!

Je viens de le tester moi-même par accident et cela empêchait les utilisateurs de se connecter avec succès. Pour résoudre ce problème, je devais démarrer en mode de récupération et le remettre en place. (Heureusement, je l'ai fait sur une machine virtuelle que je n'utilise que pour tester des choses, donc cela ne m'a pas posé de problème.)

3. Pour un utilisateur: .pam_environment dans le répertoire de base de l'utilisateur

L'un des moyens de définir une variable d'environnement pour un utilisateur unique consiste à modifier (ou à créer) .pam_environment dans son répertoire de base. Les valeurs définies dans ce fichier remplacent celles définies dans le fichier global /etc/environment.

.pam_environment ne fait pas partie du squelette de fichiers copié dans le dossier de base d'un 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 PATHname__. Contrairement à /etc/environment (mais comme /etc/security/pam_env.conf), les fichiers .pam_environment par utilisateur prennent en charge le développement de l'ancienne valeur d'une variable d'environnement dans une nouvelle. Cependant, ce ne sont pas des scripts 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 tel que .profile.

Par exemple, si vous souhaitiez ajouter un répertoire bin2 dans votre répertoire personnel à la fin de PATHname__, vous pouvez le faire en ajoutant cette ligne à .pam_environment:

PATH DEFAULT=${PATH}:/home/@{PAM_USER}/bin2

Voir la sous-section ~/.pam_environment sur VariablesEnvironnement (à partir de laquelle l'exemple ci-dessus est étroitement adapté), man pam_env , et man pam_env.conf pour 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, il reste considéré comme un choix raisonnable et acceptable , mais vous devez faire attention lorsque vous éditez .pam_environment. Comme pour les modifications apportées à /etc/security/pam_env.conf dans tout le système (voir ci-dessus), une ligne mal formée dans le fichier .pam_environment d'un utilisateur empêchera les connexions de réussir. (J'ai testé cela - volontairement cette fois.) Pour plus d'informations sur la manière dont les recommandations ont évolué , voir Gunnar Hjalmarsson - commentairesci-dessous et cette discussion ubuntu-devel .

Une telle erreur est beaucoup moins grave en général, qu'une ligne malformée dans pam_env.conf, car elle n'affecte qu'un seul utilisateur. Toutefois, dans le cas d’un système Ubuntu de bureau avec un seul compte utilisateur autorisant les connexions, une telle erreur lors de l’édition de .pam_environment sera aussi grave qu’une édition de pam_env.conf - si vous n’êtes pas déjà connecté, vous ne le ferez pas. être capable de le réparer sans démarrer en mode de récupération (ou à partir d'une clé USB, etc.).

(Si vous avez d'autres comptes utilisateur, 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 Sudoà la racine, ils peuvent toujours exécuter su your-account et être invités à entrer leur (pas leur ) mot de passe. Le compte invité ne peut cependant pas le faire car il est interdit d’utiliser supour prendre l’identité d’un autre utilisateur.)

4. Pour tous les utilisateurs: /etc/profile et les fichiers dans /etc/profile.d/

Les shells compatibles Bourne (y compris bashname__, l'utilisateur par défaut de Shell dans Ubuntu) exécutent les commandes dans /etc/profile lorsqu'ils sont appelés en tant que shell de connexion.

Le /etc/profile.d d'Ubuntu 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

Ainsi, les commandes de tout fichier du répertoire /etc/profile.d/ dont le nom se termine par .sh sont également exécutées.

La plupart des gestionnaires d’affichage demandent également l’exécution des commandes dans /etc/profile (et donc des fichiers dans /etc/profile.d) pour les connexions graphiques. Cependant, ne le fait pas tous, et c'est un argument important en faveur de l'utilisation des fonctionnalités fournies par PAM à la place (voir ci-dessus) - à moins qu'il n'y en ait jamais toute connexion graphique à ce système, ce qui pourrait être le cas, par exemple, s'il s'agit d'un serveur sur lequel aucune interface graphique n'est installée.

Il est de tradition de définir des variables d'environnement à l'échelle du système dans /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 dans /etc/profile.d/ plutôt que de modifier /etc/profile lui-même. Une des raisons est que, lors de la mise à niveau d’Ubuntu, il peut y avoir un nouveau fichier par défaut /etc/profile. En fonction de la manière dont vous effectuez la mise à niveau, l'ancien fichier (avec vos modifications) sera conservé, renonçant à 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 /etc/profile et un ou plusieurs fichiers dans /etc/profile.d, la dernière opération est effectuée? Cela dépend si les commandes dans /etc/profile qui les définissent apparaissent avant ou après les fichiers dans profile.d été recherché (par le code que j'ai cité ci-dessus). Les commandes dans /etc/profile sont exécutées dans l'ordre dans lequel elles apparaissent.

/etc/profile est un script Shell et sa syntaxe est not ​​identique à celle des fichiers de configuration de PAM décrits ci-dessus . Sa syntaxe est identique à celle du fichier ~/.profile par utilisateur (voir ci-dessous).

Si vous devez écrire du code qui décide s'il faut ou non ajouter un répertoire particulier à PATH(et pour tous les utilisateurs), vous ne pourrez pas utiliser /etc/environment ou /etc/security/pam_env.conf pour le faire. C’est peut-être la situation principale où il est préférable d’utiliser plutôt /etc/profile ou /etc/profile.d/.

5. Pour un utilisateur: .bash_profile dans le répertoire de base de l'utilisateur

Si un utilisateur a ~/.bash_profile, bash l’utilise au lieu de ~/.profile ou ~/.bash_login (voir ci-dessous). Vous ne devriez généralement pas avoir un .bash_profile dans votre répertoire personnel.

Si vous le faites, il devrait généralement contenir une commande pour générer ~/.profile (par exemple, . "$HOME/.profile"). Sinon, le contenu du fichier .profile par utilisateur n'est pas exécuté du tout.

6. Pour un utilisateur: .bash_login dans le répertoire de base de l'utilisateur

Si un utilisateur a ~/.bash_login, bash l’utilise au lieu de ~/.profile (voir ci-dessous), sauf si ~/.bash_profile existe, auquel cas aucun des autres ne sera utilisé à moins que ne soit tiré de `~/.bash_login.

Comme avec .bash_profile, vous ne devriez généralement pas avoir de fichier .bash_login dans votre répertoire personnel.

7. Pour un utilisateur: .profile dans 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 de /etc/profile (qui incluent généralement les commandes qui entraînent l'exécution des commandes des fichiers de /etc/profile.d/ - voir ci-dessus). Ensuite, il exécute les commandes dans .profile dans le répertoire de base de l'utilisateur. Ce fichier est séparé pour chaque utilisateur. (Bash exécute en fait .bash_profile ou .bash_login s'il existe - mais, pour les utilisateurs d'un système Ubuntu, ces fichiers devraient rarement exister. Pour plus de détails, voir ci-dessus et 6.2 Fichiers de démarrage Bash in - le manuel de Bash .)

~/.profile est donc l'endroit principal où l'utilisateur peut placer les commandes qui s'exécutent lorsqu'il se connecte. C’est l’endroit habituel pour définir votre PATHname__, mais comme Ubuntu possède le module pam_env et 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. C’est une raison pour préférer ~/.pam_environment pour la définition de variables d’environnement (dans la mesure où l’on peut préférer /etc/environment à /etc/profile).

Vous pouvez développer les variables d’environnement, y compris PATHname__, lorsque vous définissez PATHdans .pam_environment (voir ci-dessus). Toutefois, si vous devez définir PATHde manière plus sophistiquée, vous devrez peut-être utiliser .profile à la place. En particulier, si vous voulez vérifier si un répertoire existe chaque fois qu'un utilisateur se connecte et ne l'ajouter qu'à PATHname__, vous ne pourrez pas utiliser votre fichier .pam_environment pour l'ajouter à votre PATHname__.

Par exemple, le fichier .profile par utilisateur sous Ubuntu tilisé pour se termine 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 sur réponse du Byte Commander pour plus de détails.

Ceci vérifie si vous avez un sous-répertoire binde votre répertoire personnel. Si tel est le cas, il ajoute ce sous-répertoire au début de votre PATHname__.

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 ~/.bashrc et /etc/bash.bashrc, car ils ne sont généralement pas des emplacements recommandés pour définir PATHet il est rare que vous deviez les utiliser à cette fin. Si vous utilisez ces fichiers pour ajouter des répertoires à PATHname__, ils seront parfois ajoutés plusieurs fois et sont très déroutants 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.)

bashétant le shell de connexion par défaut d'Ubuntu pour les utilisateurs, et la plupart des utilisateurs l'utilisant 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 tcshname__.

21
Eliah Kagan

/ etc/environment le fichier n'est pas un fichier de script que vous ne pouvez pas utiliser pour exporter et il ne prend pas en charge le développement de variable de type $ HOME, il s'agit simplement de paires simplevariable = valeur. Donc, pour utiliser ce fichier, vous devez simplement ajouter votre chemin à la définition existante. Ce fichier est spécifiquement conçu pour les paramètres de variable d'environnement à l'échelle du système. un par ligne. Plus précisément, ce fichier stocke les paramètres régionaux et de chemin d'accès à l'échelle du système.

~/.profile - Ce fichier est exécuté chaque fois qu'un shell bash est exécuté, il est généralement recommandé pour les variables d'environnement. Cependant, il présente l'inconvénient d'être appelé uniquement par des shells de login. Pour prendre effet, vous devrez vous déconnecter et vous reconnecter - ou du moins, créer un nouveau shell de connexion.

3
eGhoul

L'endroit préféré pour définir les variables d'environnement dépend de plusieurs facteurs:

  1. Êtes-vous le seul à utiliser l'ordinateur:
    • Dans ce cas, le meilleur endroit pour le définir serait dans le /etc/environment car il n'y a pas de danger d'accès _ non autorisé.
  2. Si le système est utilisé par plusieurs
    • Si les variables devaient être accessibles à tous, l'emplacement serait /etc/environment, mais
    • si des utilisateurs individuels doivent avoir choisi l'accès, puis chacun d'entre eux doit le définir dans le ~/.profile appartenant à chaque utilisateur du système puisqu'il se trouve dans le répertoire de base de chaque utilisateur.

Le système lira /etc/environment avant de lire ~/.profile. Aucune concaténation ne se produit et comme Alex P dit le dernier l'affectation au chemin prévaut.

Pour plus de détails sur les facteurs qui déterminent comment ~/.profile et /etc/environment se jouent avec d’autres emplacements de ce type, allez ici et ici , des facteurs influenceront votre utilisation de ces lieux.

1
George Udosen