110 votes

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

Quel est l'endroit préféré pour placer le PATH envvar ?

~/.profile o /etc/environment ?

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

126voto

Byte Commander Points 99026

Résumé :

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

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

    Notez que les priorités des chemins sont décroissantes de gauche à droite, de sorte que le premier chemin a la plus haute priorité. Si vous ajoutez votre chemin à gauche de $PATH il aura la plus haute priorité et les exécutables dans 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.

  • Cependant, si vous avez besoin de définir cette variable d'environnement pour tous les utilisateurs, je ne recommanderais toujours pas de toucher à /etc/environment mais la création d'un fichier avec le nom de fichier se terminant par .sh en /etc/profile.d/ . Le site /etc/profile script et tous les script dans /etc/profile.d sont l'équivalent global des données personnelles de chaque utilisateur. ~/.profile et exécutés comme des Shell Shell ordinaires par tous les shells pendant leur initialisation.


Plus de détails :

  • /etc/environment est un fichier de configuration pour l'ensemble du système, ce qui signifie qu'il est utilisé par tous les utilisateurs. Il est la propriété de root Cependant, vous devez être un utilisateur admin et utiliser la fonction sudo pour le modifier.

  • ~/.profile est un des Shelld'initialisation de votre propre utilisateur Shell. Chaque utilisateur en possède un et peut modifier son fichier sans affecter les autres.

  • /etc/profile y /etc/profile.d/*.sh sont les scripts d'initialisation globale qui sont équivalents à ~/.profile pour chaque utilisateur. Les scripts globaux sont exécutés avant les scripts spécifiques à l'utilisateur ; et le principal /etc/profile exécute toutes les *.sh scripts en /etc/profile.d/ juste avant sa sortie.


  • El /etc/environment ne contient normalement que cette ligne :

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

    Il fixe le PATH pour tous les utilisateurs du système à cette valeur par défaut, qui ne doit pas être modifiée de manière importante. Au moins, vous ne devriez pas supprimer les chemins importants tels que /bin , /sbin , /usr/bin y /usr/sbin d'elle.

    Ce fichier est lu comme l'un des premiers fichiers de configuration par chaque Shell de chaque utilisateur. Notez qu'il est pas un Shell Shell . Il s'agit simplement d'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 !

  • El ~/.profile peut contenir de nombreuses choses, par défaut il contient entre autres une vérification si un fichier ~/bin et l'ajoute au répertoire existant de l'utilisateur. PATH comme ceci (sur les anciennes versions d'Ubuntu antérieures à la 16.04 -- qui l'ajoute sans condition -- et sur la 18.04, qui ajoute également "~/.local/bin") :

    # 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é ici et le nouveau chemin est seulement ajouté au début au lieu de tout écraser. Lorsque vous souhaitez ajouter manuellement de nouveaux chemins, vous devez également toujours conserver l'ancien chemin d'accès $PATH quelque part dans la nouvelle chaîne.

    Cette initialisation script n'est lue que par les shells de l'utilisateur auquel elle appartient, mais il y a 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.

    Ainsi, si vous utilisez le Shell par défaut de Bash, vous devez vous assurer que vous n'avez pas de ~/.bash_profile o ~/.bash_login si vous voulez que les changements dans ~/.profile pour avoir un effet sur votre utilisateur.


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


Question connexe : différence entre bash.bashrc et le fichier /etc/environment

37voto

Eliah Kagan Points 111731

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 .

4voto

Moshe Simantov Points 479

/etc/environnement n'est pas un fichier script, vous ne pouvez pas utiliser export et il ne supporte pas l'expansion de variables du type $HOME, juste de simples paires variable=valeur. Donc, pour utiliser ce fichier, vous devez simplement ajouter votre chemin à la définition existante, est spécifiquement destiné aux paramètres de variables d'environnement à l'échelle du système. un par ligne. Plus précisément, ce fichier stocke les paramètres régionaux et les chemins d'accès de l'ensemble du système.

~/.profil - Ce fichier est exécuté chaque fois qu'un Shell bash est exécuté, c'est généralement celui qui est recommandé pour les variables d'environnement, cependant il a l'inconvénient de n'être invoqué que par les shells de connexion, donc pour qu'il prenne effet vous devrez vous déconnecter et vous reconnecter - ou au moins, démarrer un nouveau Shell de connexion.

2voto

George Udosen Points 33267

L'endroit préféré pour mettre variables environnementales dépend de plusieurs choses :

  1. Vous êtes le seul à utiliser l'ordinateur :
    • Dans ce cas, le meilleur endroit pour le mettre en place serait dans l'onglet /etc/environment puisqu'il n'y a pas de danger d'accès non autorisé.
  2. Si le système est utilisé par de nombreux
    • Si le variables devrait être accessible à tous, alors l'emplacement serait /etc/environment mais
    • si utilisateurs individuels devrait avoir choisi d'y accéder alors chacun doit définir le sien dans le ~/.profile appartenant à chaque utilisateur du système puisqu'il est situé dans le répertoire personnel de chaque utilisateur.

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

Pour un examen plus détaillé des facteurs qui déterminent comment ~/.profile y /etc/environment jouer avec d'autres lieux de ce type vont ici y ici car ces facteurs influenceront la façon dont vous utiliserez ces lieux.

0voto

Good Pen Points 111

Bash lit ces fichiers, mais zsh ne le fait pas :

  1. à l'échelle du système

    /etc/profile - Ce n'est pas une bonne idée de l'éditer directement.
    /etc/profile.d/*.sh - provenant de /etc/profile

  2. à l'échelle de la session

    ~/.profile

https://help.ubuntu.com/community/EnvironmentVariables#A.2Fetc.2Fprofile.d.2F.2A.sh

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X