Quels sont les endroits appropriés pour:
- Variables d'environnement globales destinées à affecter tous les utilisateurs?
- Variables d'environnement spécifiques à l'utilisateur?
Pour ajouter à la réponse de sagarchalise, je peux résumer ce que le lien suggère comme lieux appropriés pour les paramètres.
/etc/environment
/etc/profile
ou /etc/bash.bashrc
De la page:
/etc/environment
[...] est spécifiquement conçu pour l'ensemble du système paramètres de variable d'environnement. C'est pas un fichier script, mais plutôt composé des expressions d'affectation, une par ligne. Plus précisément, ce fichier stocke les paramètres régionaux et le chemin d'accès à l'échelle du système paramètres.
L'utilisation de /etc/profile
est une méthode très Unix-y, mais ses fonctionnalités sont considérablement réduites sous Ubuntu. Il existe uniquement pour pointer vers /etc/bash.bashrc
et pour collecter les entrées de /etc/profile.d
.
Sur mon système, la seule entrée intéressante dans profile.d est /etc/profile.d/bash_completion.sh
.
Une version précédente de la page Ubuntu recommandait ~/.pam_environment
, mais la page suggère que si cela ne fonctionne pas, vous devriez utiliser
~/.profile
- Ceci est probablement le meilleur fichier pour placer l'environnement affectations variables dans, car il devient exécuté automatiquement par le DisplayManager lors du démarrage traiter la session de bureau ainsi que par le shell de connexion lorsque l'on se connecte depuis la console textuelle.
~/.bash_profile
ou ~./bash_login
- Si l'un d'eux existe, bash l'exécute au lieu de ~/.profile
lorsque bash est démarré en tant que shell de connexion. Bash préférera ~/.bash_profile
à ~/.bash_login
. [...] Ces fichiers n'influencent pas une session graphique par défaut. "
~/.bashrc
- "... peut être l'endroit le plus facile pour définir des variables". Vous avez:
/ etc / profile: fichier .profile à l’échelle du système pour le shell Bourne (sh (1)) et shell compatibles Bourne (bash (1), ksh (1), ash (1), ...).
qui, dans Lucid et Maverick, s'exécute
/etc/profile.d/*.sh
si présent, et si le shell de l'utilisateur est bash:
/etc/bash.bashrc
Pour l'environnement utilisateur, il existe un tableau déroutant spécifique au shell et indiquant s'il est considéré comme un "shell de connexion". Si le shell est bash:
~/.bash_profile
The personal initialization file, executed for login shells
~/.bashrc
The individual per-interactive-shell startup file
pour sh / dash:
$HOME/.profile
pour zsh, je ne vais même pas essayer de donner un sens à cela .
Comme recommandé sur lien :
Les variables d'environnement globales destinées à affecter tous les utilisateurs doivent aller dans /etc/environment
.
Les variables d'environnement spécifiques à l'utilisateur doivent être définies dans ~/.pam_environment
.
Évitez les fichiers de profil et rc pour définir les variables d’environnement sur Ubuntu. Ils m'ont causé plus de maux de tête que ce qu'ils valent.
C'est plus facile à dire qu'à faire cependant;)
Il est possible que vous rencontriez le même problème de configuration que moi. Voir la solution de contournement pour la maison chiffrée ci-dessous.
~/.pam_environment
: PATH DEFAULT=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:${HOME}/bin
IDEA_JDK DEFAULT=${HOME}/Applications/jdk
Pourquoi le chemin statique laid? ${PATH}
ne fonctionnerait pas pour moi. J'ai bricolé mon login plusieurs fois en essayant de le contourner, donc je reste fidèle à la copie statique laide des défauts:)
Dans les versions d’Ubuntu jusqu’à Precise 12.04 Beta 2 inclus, si vous utilisez un répertoire personnel chiffré, vous devrez modifier /etc/pam.d/common-session
pour le charger ~/.pam_environment
. Cette solution fonctionne apparemment pour les versions précédentes, mais je ne l'ai pas testée.
Cela semble être un problème avec les répertoires personnels chiffrés. J'ai ajouté
session requise pam_env.so
à la fin de /etc/pam.d/common-session et maintenant ~ / .pam_environment est lu. Sur un autre système sans répertoires personnels chiffrés (également 10.04), le travail n'est pas nécessaire. Peut-être que dans mon cas, le système essaie de lire ~ / .pam_environment avant de le déchiffrer.
Adapté de ma réponse sur Super User: lien
Lire d'autres questions sur les étiquettes command-line environment-variables