Variables d'environnement dans bash_profile ou bashrc?

Sur un système moderne, il n'est pas particulièrement fréquent de rencontrer les cas où cela importe, mais cela se produit. (En particulier, si vous utilisez des opérations shell dans vim telles que :r !command Ou le formulaire de !<motion>command en ligne !<motion>command ).

Que metriez-vous sous ~ / .bashrc? Seulement des alias?

Vous mettez des choses dans ~/.bashrc qui ne seraient pas héritées par des sous-sections automatiquement; Cela signifie des alias et des fonctions, en grande partie, bien que parfois vous ayez des paramètres variables que vous ne voulez pas visibles en dehors du shell (ce qui est très rare). On pourrait soutenir que ceux-ci devraient être exportés en quelque sorte, mais diverses tentatives expérimentales ont rencontré des problèmes de compatibilité en essayant de les cacher dans l'environnement et ont été abandonnées en grande partie.

Si je veux définir une variable d'environnement et l'ajouter au PATH (par exemple, JAVA_HOME) où serait-il le meilleur endroit pour mettre l'entrée d'exportation? Dans ~ / .bash_profile ou ~ / .bashrc?

Vous mettez les paramètres d'environnement dans ~/.bash_profile afin qu'ils reçoivent des paramètres initiaux sains. Parfois, vous voudrez remplacer ces (souvent cela se fait par des environnements complexes tels que Matlab ou Cadence); Si vous mettez les paramètres de l'environnement dans ~/.bashrc shells exécutés à partir de ces environnements perdront les personnalisations des environnements, et les choses risquent de ne pas fonctionner correctement. Cela s'applique également si vous utilisez un paquet comme des modules , virtualenv , rvm , etc. pour gérer plusieurs environnements de développement; Mettre vos paramètres dans ~/.bashrc signifie que vous ne pouvez pas exécuter l'environnement que vous voulez dans votre éditeur, mais plutôt forcé dans le système par défaut.

Dans un shell non connecté, je crois que le ~ / .bash_profile n'est pas "ramassé".

C'est correct; Vous souhaitez normalement que le shell initial soit un shell de connexion et que les shells commencent sous celui-ci pour ne pas être des shells de connexion. Si le shell initial n'est pas un shell de connexion, vous ne disposerez pas d'un PATH par défaut ou de plusieurs autres paramètres (y compris votre exemple JAVA_HOME ).

La plupart des environnements de bureau lancés à partir des gestionnaires d'affichage (c'est-à-dire la grande majorité des connexions graphiques) ne configurent pas un environnement de connexion pour l'ensemble du bureau, de sorte que vous devez exécuter le shell initial dans les terminaux en tant que shell de connexion. Cela cause un certain nombre de problèmes (notamment que le PATH et ceux disponibles pour les programmes s'exécutent à partir, par exemple, des panneaux n'est pas configuré correctement, car le panneau n'est pas un terminal et n'a pas exécuté ~/.bash_profile ), mais est un compromis raisonnable étant donné que Il n'est pas toujours possible de gérer correctement ~/.bash_profile dans l'environnement non interactif au début d'une session démarrée par un gestionnaire d'affichage en fonction de son contenu. Il est parfois suggéré de placer des paramètres d'environnement dans ~/.bashrc au lieu de configurer un shell de connexion à la place; Comme discuté ci-dessus, cela fonctionne aussi longtemps que vous n'avez pas besoin de remplacer cet environnement et cause des ruptures anormales une fois que vous avez besoin de le faire.

J'ai récemment aidé à diagnostiquer un problème comme celui-ci sur OS X où un utilisateur qui avait placé des paramètres dans ~/.bashrc puis a commencé à utiliser rvm et perlbrew ont vu un comportement étrange, car les environnements configurés par les deux étaient "défectueux" par ~/.bashrc intérieur des éditeurs et du sudo (ce qui sur OS X, contrairement à Linux, propage le $HOME l'utilisateur afin que leur ~/.bashrc soit exécuté par le shell racine). Avant d'essayer d'utiliser ces environnements, il n'y avait aucun problème; En commençant à les utiliser, ils ont été déconcertés par la perte inattendue de leurs paramètres.

Pour être honnête, il y a peu de différence ces jours-ci malgré ce que le gourou devait dire.

Le problème derrière cela est que, de nos jours, nous nous connectons de manière graphique plutôt que via un shell de connexion. Dans le passé, nous, les utilisateurs d'unix, aiment voir un court rapport de ce qui se passe sur un serveur immédiatement après la connexion – alors nous allons commencer X par ligne de commande – ces rapports nécessitent souvent un certain temps pour générer (par ex. 10-20 secondes). Et nous ne voulons pas voir le même quand on commence par exemple xterm. Donc la différence.

De nos jours, je ne pense pas que la distinction soit importante maintenant. Je pense que ces jours-ci, si vous sourcez bashrc dans bash_profile, personne ne pourrait vous reprocher.

Notez que cela ne s'applique pas à macos x (chaque terminal.app démarre est un shell de connexion)

Eh bien, à propos de "Logins Graphiques", cela dépend de laquelle * DM vous utilisez …

Avec GDM (Gnome 3.18), j'ai ceci:

/ Etc / gdm / Xsession

 #!/bin/sh <= *important* ... # First read /etc/profile and .profile test -f /etc/profile && . /etc/profile test -f "$HOME/.profile" && . "$HOME/.profile" # Second read /etc/xprofile and .xprofile for X specific setup test -f /etc/xprofile && . /etc/xprofile test -f "$HOME/.xprofile" && . "$HOME/.xprofile" 

Donc, ~ / .profile est obtenu dans la connexion en utilisant / bin / sh et non / bin / bash

Il y a deux cas

1. / Bin / sh est lié à / bin / bash mais s'exécute en mode "POSIX / Bourne"
2. / Bin / sh est / bin / dash (debian / ubuntu). Le plus rapide mais avec moins de fonctionnalités (support ShellShock;) )

Donc, le profil / bin / sh est ~ / .profile et non ~ / .bash_profile, ~ / .zprofile

Ce fichier doit être utilisé pour les paramètres "shell agnostic" , comme les variables de chemin d'accès et d'environnement.

NON un programme exécutable pour l'interaction de l'utilisateur de connexion uniquement devrait être ici (vérification de la poste, fortune, etc.)

Les ~ /.* rc ne sont destinés qu'à des sessions "interactives" (alias par exemple …)

Il existe une différence entre bash et zsh pour les shells de connexion interactifs

Bash sources seulement .bash_profile, tandis que les sources zsh dans l'ordre:

1. ~ / .zprofile
2. ~ / .zshrc
3. ~ / Zlogin (ici les alias définis dans ~ / .zshrc sont disponibles. En cas de shells "interactifs" + "connexion"

La bonne façon de faire ~ / .bash_profile a été répondu ici:

Différence entre .bashrc et .bash_profile

 if [ -r ~/.profile ]; then . ~/.profile; fi case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac 

Pour activer le test (et le profilage), vous pouvez utiliser ceci

~ / .bash_profile:

 #!/bin/bash # ------------------------------------------------ export _DOT_BASH_PROFILE_0=`date --rfc-3339=ns` # ------------------------------------------------ if [ -f ~/.profile ] ; then . ~/.profile fi case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac # ------------------------------------------------ export _DOT_BASH_PROFILE_1=`date --rfc-3339=ns` # ------------------------------------------------ 

~ / .zprofile:

 #!/bin/zsh # ------------------------------------------------ export _DOT_ZSH_PROFILE_0=`date --rfc-3339=ns` # ------------------------------------------------ if [ -f ~/.profile ] ; then . ~/.profile fi # no need to source, zsh already handle ~/.zshrc ###case "$-" in *i*) if [ -r ~/.zshrc ]; then . ~/.zshrc; fi;; esac # ------------------------------------------------ export _DOT_ZSH_PROFILE_1=`date --rfc-3339=ns` # ------------------------------------------------ 

Ensuite, pour tester:

 chsh -s /bin/bash ssh localhost env exit ssh localhost env ssh -t localhost bash -i -c env chsh -s /bin/zsh ssh localhost env exit ssh localhost env ssh -t localhost bash -i -c env 

Alors RVM / virtualenv devrait être dans ~ / .profile, IMHO

Mais cela ne fonctionne pas , parfois …

Par exemple, virualenvwrapper fonctionne uniquement si le shell exécutant Xsession est un bash "original" (exportant BASH_VERSION)

Si vous êtes sur un système de tableau de bord , la variable d'environnement et le paramètre de cheminement fonctionnent, mais la définition de la fonction virualenvwrapper ne fonctionne pas car le script n'est pas compatible POSIX.

Le script ne donne aucune erreur, mais il se termine sans aucune définition "workon" .

Vous pouvez donc configurer l'environnement à l'aide de ~ / .profile , juste pour permettre l'exécution correcte de python du client démarré directement à partir de X:

 export VIRTUAL_ENV="/home/mike/var/virtualenvs/myvirtualenv" export PATH="$VIRTUAL_ENV/bin:$PATH" unset PYTHON_HOME 

https://gist.github.com/datagrok/2199506

https://www.bountysource.com/issues/9061991 -setting-up-your-computer-virtualenvwrapper-linux-all

Mais pour virualenvwrapper, vous avez deux alternatives:

1. Source dans ~ / .bash_profile ou ~ / .zprofile (ou ~ / .zlogin) lorsque le terminal agit comme un shell de connexion
2. Inclure le script dans ~ / .bashrc ou ~ / zshrc

Cela signifie que les clients X (emacs, par exemple) doivent être démarrés à partir du boîtier du terminal et non à partir du graphique.

"Je ne peux pas obtenir de satisfaction …"