Variables d'environnement dans bash_profile ou bashrc ?

Pour être honnête, il n'y a guère de différence aujourd'hui, malgré ce qu'a dit le gourou.

le problème est que de nos jours, nous nous connectons graphiquement plutôt que par le biais d'une connexion Shell. dans le passé, nous, utilisateurs d'unix, aimions voir un bref rapport sur ce qui se passait sur un serveur immédiatement après la connexion - puis nous démarrions X en ligne de commande - ces rapports prennent souvent un certain temps à être générés (par exemple 10-20 secondes). et nous ne voulons pas voir la même chose lorsque nous démarrons par exemple xterm. c'est pourquoi il y a une différence.

De nos jours, je ne pense pas que la distinction soit importante. Je pense que de nos jours, si vous sourcez bashrc dans bash_profile, personne ne pourra vous le reprocher.

note : ceci ne s'applique pas à macos x (chaque terminal.app démarré est un login Shell)

En ce qui concerne les "Logins graphiques", cela dépend de la *DM que 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"

Ainsi, ~/.profile est obtenu lors de l'ouverture de session à l'aide de /bin/sh et non /bin/bash

Il y a deux cas de figure

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

Le profil /bin/sh est donc ~/.profile et non ~/.bash_profile, ~/.zprofile

Ce fichier doit être utilisé pour "Shell agnostique" comme les chemins d'accès et les variables d'environnement.

NON le programme exécutable destiné à l'interaction avec l'utilisateur connecté doit être placé ici (vérification du courrier, fortune, etc...)

les ~/.*rc ne sont destinés qu'aux sessions "interactives" (alias par exemple ...)

Il y a une différence entre bash et zsh pour l'interactivité. connexion coquilles

bash n'utilise que le fichier .bash_profile, tandis que zsh utilise les sources dans l'ordre :

1. ~/.zprofile
2. ~/.zshrc
3. ~/zlogin (les alias définis dans ~/.zshrc sont disponibles dans le cas des shells "interactive" + "login")

La bonne façon de faire ~/.bash_profile a fait l'objet d'une réponse 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`
# ------------------------------------------------

puis, de 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

RVM/virtualenv devrait donc être placé dans ~/.profile, selon moi.

Mais cette NE FONCTIONNE PAS , parfois ...

Par exemple, virualenvwrapper ne fonctionne que si l'option Shell est activée. qui exécute Xsession est un bash "original" (exportant BASH_VERSION)

Si vous êtes sur un tiret la variable d'environnement et le chemin d'accès fonctionnent, mais le système virualenvwrapper ne fonctionnent pas car le script n'est pas compatible avec POSIX.

Le script ne donne pas d'erreur mais il se termine sans rien dire. "workon" définition.

Vous pouvez donc définir l'environnement en question dans ~/.profile pour permettre l'exécution correcte de Python à partir d'un client démarré directement depuis 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 possibilités :

1. le sourcer dans ~/.bash_profile o ~/.zprofile (ou ~/.zlogin) lorsque le terminal joue le rôle de login Shell.
2. inclure le script dans ~/.bashrc o ~/zshrc

Cela signifie que les clients X (emacs par exemple) doivent être lancés à partir du terminal Shell et non à partir du client graphique !

"Je n'arrive pas à obtenir satisfaction..."