Pourquoi .profile (et non .bashrc) ajoute ~ / bin au chemin?

9

Puisqu'il .bashrcest plus "générique" (dans le sens où .profileil le fournit), pourquoi la ~/binprocédure "inclure dans le chemin" n'est pas à l'intérieur .bashrc? Pourquoi l'utilisateur ne le voudrait pas dans un shell sans connexion? (Surtout de nos jours, où les shells sans connexion sont plus courants *.)

Je sais que je peux effectuer manuellement un tel changement, mais je veux savoir s'il y a une raison.

* ne peut pas le prouver, mais je pense que c'est le cas.

command-line bash .profile

— borges
source

13

~/.bashrcet /etc/bash.bashrcsont exécutées à chaque démarrage d'un bashshell interactif .

En revanche, ~/.profileet /etc/profilesont exécutés chaque fois qu'une connexion shell est lancé. Il ne doit donc pas être un bashshell, mais il doit être un shell de connexion (et de nombreuses bashinstances de shell ne sont pas des shells de connexion ).

Un bashshell est un shell où se trouve le programme shell qui le fournit bash, plutôt qu'un autre programme tel que dash.
Un shell de connexion est un shell qui démarre automatiquement à la suite de la connexion, pour fournir l'interface utilisateur (graphique ou ligne de commande) pour la connexion. Lorsqu'un shell de connexion est fermé, la connexion se termine.

Par conséquent, la mise en place d'une recommandation qui ajoute des entrées à PATHun bashrcfichier:

Ne faites rien lorsque la coque n'est pas bash, ce qui est souvent le cas. Par exemple, PATHne serait pas modifié lorsque vous êtes dans une session de connexion graphique. N'oubliez PATHpas qu'il n'est pas uniquement utilisé par les programmes en ligne de commande.
Ajoutez-le encore et encore en présence de bashcoquilles imbriquées . Donc, si vous démarrez un shell dans un shell - ce qui est très courant, pour diverses raisons - alors vous aurez plusieurs ~/binentrées empilées sur votre PATH. Cela rend la PATHvariable d'environnement difficile à lire et diminue parfois les performances.

Ce ne serait pas souhaitable. Il serait donc faux de mettre cela dans un bashrcfichier; il appartient vraiment ~/.profile. ~/.profileest le bon endroit pour:

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

Les shells sans connexion ont des shells de connexion (ou quelque chose qui se comporte comme un shell de connexion) comme parent et héritent de la plupart de leurs variables d'environnement, y compris PATHde ce shell de connexion. Ainsi, la mise en place de commandes modifiant le chemin ~/.profilenécessite que vous vous déconnectiez et vous reconnectiez pour qu'elles soient efficaces, mais cela affecte également l'environnement des shells sans connexion (ainsi que l'environnement des programmes qui ne sont pas des shells, car chaque programme obtient son propre ensemble de variables d'environnement - appelé son "environnement" - hérité de son processus parent).

— Eliah Kagan
source

Je comprends. Mais cette décision n'a toujours pas de sens pour moi. Si un terminal ouvert en ce moment ne charge que .bashrc, alors je ne pourrai pas voir mon bac privé.

— borges

@borges Si la configuration par défaut ne vous convient pas, n'hésitez pas à la modifier. (C'est votre ordinateur, après tout. Ou du moins votre compte.) Mais cela ressemble à une chose unique. Autrement dit, il semble que votre binrépertoire privé n'existait pas lorsque vous vous êtes connecté et que vous l'avez créé pendant cette session de connexion. Si vous vous déconnectez et vous reconnectez, ce sera dans votre dossier PATH. Étant donné que la création de votre binrépertoire privé est quelque chose qui ne doit être effectué qu'une seule fois, il s'agit d'un inconvénient ponctuel.

— Eliah Kagan

3

C'est parce que traditionnellement les variables d'environnement ne vont que dans /etc/profileou .profile. Le bashrcfichier est destiné à des choses comme les alias, les paramètres d'invite, les options du shell, etc. (c'est-à-dire les choses qui se rapportent directement au shell).

— teppic
source