Question Choisir entre .bashrc, .profile, .bash_profile, etc. [dupliquer]


Cette question a déjà une réponse ici:

C'est embarrassant, mais après plusieurs années d'utilisation des systèmes POSIX à temps plein, j'ai encore du mal à déterminer si une personnalisation du shell devrait être mise en œuvre. .bashrc, .profile, ou ailleurs. Sans parler de certains fichiers de configuration spécifiques à l'OS, tels que .pam_environment.

Oui, je sais comment déchiffrer la documentation et apprendre quand chaque fichier est ou non chargé. Ce que je me demande, c'est si quelqu'un a mis au point des directives complètes sur la manière de décider dans quel fichier placer un type de personnalisation donné.


169
2017-07-29 03:14


origine


cette question ne doit pas être marquée comme étant en double la raison est que .profile n'est pas disponible dans la question ajoutée. - Premraj
Ans: serveurfault.com/q/261802/270464 - Premraj


Réponses:


TL; DR:

  • ~/.bash_profile devrait être super simple et juste charger .profile et .bashrc (dans cet ordre)

  • ~/.profile a les choses pas spécifiquement liées à bash, telles que les variables d'environnement (PATH et amis)

  • ~/.bashrc a tout ce que vous voulez sur une ligne de commande interactive. Invite de commande, EDITOR variables, alias bash pour mon usage

Quelques autres notes:

  • Tout ce qui devrait être disponible pour les applications graphiques OU pour sh (ou bash invoqué en tant que sh) DOIT être dans ~/.profile

  • ~/.bashrc ne doit rien sortir

  • Tout ce qui ne devrait être disponible que pour connecter des shells devrait aller dans ~/.profile

  • Veiller à ce que ~/.bash_login n'existe pas.


190
2017-07-29 04:27



+1, cela permet ~/.profile définir correctement l'environnement pour des services tels que GDM / LightDM / LXDM qui exécutent explicitement / bin / sh. - grawity
ma .bashrc produit pas mal de choses, pouvez-vous commenter? En particulier, où dois-je mettre la sortie d'accueil? - Calimo
@ Calimo: Faites-en uniquement des sorties en mode interactif. Vous pouvez tester pour cela en utilisant [[ $- == *i* ]], c’est-à-dire chercher "i" dans la spéciale $- variable. Bien sûr, cela n’a d’importance que sur les systèmes où bash est compilé pour lire .bashrc en mode non interactif. (C'est-à-dire Debian mais pas Arch.) Mais c'est une cause fréquente de messages d'erreur mystérieux lorsque vous essayez de vous connecter en utilisant sftp ou scp ou des outils similaires. - grawity
Maintenant, je dois savoir pourquoi .bash_login n'existe pas? Qu'est ce que ça fait? - tedder42
@ tedder42: Il fait la même chose que .bash_profile et .profile. Mais bash ne lit que le premier sur trois. Signification, si vous avez un .bash_login, alors les deux .profile et .bash_profile sera mystérieusement ignoré. - grawity


Au cours des dernières années, j'ai eu beaucoup de temps à perdre, alors je avoir a fait des recherches pour un peu plus de 10 minutes. Je ne sais pas si c'est la meilleure mise en page, c'est juste une qui fonctionne correctement dans presque tous les cas.

Les exigences:

  • ~/.profile doit être compatible avec tout / bin / sh - cela inclut bash, dash, ksh, peu importe ce que la distribution peut choisir.

  • Les variables d'environnement doivent être placées dans un fichier qui est lu à la fois par les connexions à la console (c'est-à-dire un shell de connexion) et les connexions graphiques (par exemple, les gestionnaires d'affichage tels que GDM, LightDM ou LXDM).

  • Il y a très peu d'intérêt à avoir tous les deux  ~/.profile et ~/.bash_profile. Si ce dernier est manquant, bash utilisera volontiers l'ancien, et toutes les lignes spécifiques à bash peuvent être protégées par une vérification de $BASH ou $BASH_VERSION.

  • La séparation entre *profile et *rc est que le premier est utilisé pour les shells "login", et le second chaque fois que vous ouvrez une fenêtre de terminal. Cependant, bash en mode "login" ne source pas ~/.bashrc, donc ~/.profile doit le faire manuellement.

le plus simple la configuration serait:

  • Avoir un ~/.profile qui définit toutes les variables d'environnement (sauf celles spécifiques à bash), peut-être imprime une ligne ou deux, puis les sources ~/.bashrc si elle est exécutée par bash, respectez la syntaxe compatible avec sh autrement.

    export TZ = "Europe / Paris"
    export EDITOR = "vim"
    si ["$ BASH"]; puis
        . ~ / .bashrc
    Fi
    disponibilité
    
  • Avoir un ~/.bashrc qui effectue toute configuration spécifique au shell, gardée avec un chèque pour mode interactif pour éviter de casser des choses comme sftp sur Debian (où bash est compilé avec l'option de charger ~/.bashrcmême pour les coques non interactives):

    [[$ - == * i *]] || retourne 0
    
    PS1 = '\ h \ w \ $'
    
    start () {sudo service "$ 1" start; }
    

Cependant, il existe également le problème que certaines commandes non interactives (par ex. ssh <host> ls) sauter ~/.profile, mais les variables d'environnement leur seraient très utiles.

  • Certaines distributions (par exemple Debian) compilent leur bash avec l'option de source ~/.bashrc pour de telles connexions non interactives. Dans ce cas, j'ai trouvé utile de déplacer toutes les variables d'environnement (le export ... lignes) dans un fichier séparé, ~/.environ, et de le chercher à partir de tous les deux  .profile et .bashrc, avec un garde pour éviter de le faire deux fois:

    si ! ["$ PREFIX"]; puis # ou $ EDITOR, ou $ TZ, ou ...
        . ~ / .environ # généralement toute variable que .environ lui-même définirait
    Fi
    
  • Malheureusement, pour les autres distributions (par exemple, Arch), je n'ai pas trouvé de très bonne solution. Une possibilité est d'utiliser le module PAM pam_env (activé par défaut), en mettant les éléments suivants dans ~/.pam_environment:

    BASH_ENV =. /. Environ # pas une faute de frappe; il doit être un chemin, mais ~ ne fonctionnera pas
    

    Alors, bien sûr, mise à jour ~/.environ à unset BASH_ENV.


Conclusion? Les coquilles sont une douleur. Les variables d'environnement sont pénibles. Les options de compilation spécifiques à la distribution sont un immense douleur dans le cul


45
2017-07-29 15:28



+1 pour le dernier paragraphe, mais je préfère le sourcing .profile et .bashrc de .bash_profile et garder .profile nettoyer. - nyuszika7h
@ nyuszika7h: Mon .profile  est propre, Merci. - grawity
Notez que chaque fois que vous ouvrez une fenêtre, le commentaire est inversé pour OSX - Mark
"Il y a très peu d'intérêt à avoir les deux ~/.profile et ~/.bash_profile": Je suis en désaccord. Voir la réponse de Dan pour savoir pourquoi. - rubenvb
@rubenvb Pouvez-vous citer la partie pertinente? Je pense que c'est bien d'avoir seulement un .profile et garde le bashparties spécifiques aux conditionnels. - Kelvin


Regardez ça excellent article de blog par ShreevatsaR. Voici un extrait, mais allez sur le blog, il comprend une explication pour des termes tels que "login shell", un organigramme et un tableau similaire pour Zsh.

Pour Bash, ils fonctionnent comme suit. Lisez la colonne appropriée. Exécute A, puis B, puis C, etc. Le B1, B2, B3 signifie qu'il n'exécute que le premier de ces fichiers.

+----------------+-----------+-----------+------+
|                |Interactive|Interactive|Script|
|                |login      |non-login  |      |
+----------------+-----------+-----------+------+
|/etc/profile    |   A       |           |      |
+----------------+-----------+-----------+------+
|/etc/bash.bashrc|           |    A      |      |
+----------------+-----------+-----------+------+
|~/.bashrc       |           |    B      |      |
+----------------+-----------+-----------+------+
|~/.bash_profile |   B1      |           |      |
+----------------+-----------+-----------+------+
|~/.bash_login   |   B2      |           |      |
+----------------+-----------+-----------+------+
|~/.profile      |   B3      |           |      |
+----------------+-----------+-----------+------+
|BASH_ENV        |           |           |  A   |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|~/.bash_logout  |    C      |           |      |
+----------------+-----------+-----------+------+

29
2017-07-29 03:39



C'est sympa. Il est important de noter que généralement /etc/profile appels /etc/bash.bashrc, et ~/.profile appels ~.bashrc. Donc, efficacement /etc/bash.bashrc et ~/.bashrc sont également en cours d’exécution pour les connexions interactives. - wisbucky
Notez que certaines distributions semblent remplacer ce schéma (avec des conséquences étranges) - voir par exemple mon rapport de bug à opensuse ici: bugzilla.opensuse.org/show_bug.cgi?id=1078124 - Christian Herenz


Je vous propose mes directives "complètes":

  • Faire .bash_profile et .profile charge .bashrc s'il existe, par ex. [ -r $HOME/.bashrc ] && source $HOME/.bashrc
  • Mettez tout le reste dans .bashrc.
  • Arrête de t'en faire.
  • Tous les quatre ans environ, consacrez dix minutes à la recherche de cette question avant d'abandonner et de revenir à «ne pas s'inquiéter».

EDIT: Ajout de citations de peur à "exhaustif" au cas où quelqu'un serait tenté de le croire. ;)


19
2017-07-31 02:45



Avoir les deux .bash_profile et .profile est un peu redondant; vous n'avez besoin que de ce dernier. Vous devez cependant le faire / bin / sh-proof: if [ "$BASH" ] && [ -r ~/.bashrc ]; then . ~/.bashrc; fi, car il existe des programmes (à savoir gdm / lightdm) qui génèrent manuellement le fichier à partir d'un script / bin / sh. Cela signifie également que l'environnement conservé dans .bashrc serait inefficace. A eu à -1, puisque vos directives "complètes" ne fonctionneront pas sur de nombreux systèmes, car j'avais trouvé le chemin difficile plusieurs fois. - grawity
Pas de problème, je paierais avec plaisir un -1 pour une réponse qui n'est pas simplement ironique "complète", et vous avez certainement mérité ce titre. - Mechanical Fish


J'ai renoncé à essayer de trouver celui-ci et j'ai fait un script (~/.shell-setup) que je tire de tous les autres.

Cette approche nécessite ~/.shell-setup avoir deux caractéristiques:

  1. Ne s'exécute qu'une seule fois, même lorsque plusieurs sources sont utilisées (utilisation Inclure les gardes)
  2. Ne pas générer de sortie indésirable (détecter lorsque la sortie est correcte)

# 1 est assez standard, mais peut-être pas beaucoup utilisé dans les scripts shell.

# 2 est plus difficile. Voici ce que j'utilise dans bash:

if [ "" == "$BASH_EXECUTION_STRING" -a "" == "$DESKTOP_SESSION" ]; then
    echo "Hello user!" # ... etc
fi

Malheureusement, je ne me souviens pas comment je suis arrivé avec ça ou pourquoi détecter un shell interactif n'était pas suffisant


0
2017-07-29 03:50





Mettre tout dans .bashrc et puis source .bashrc de .profile

A partir de la page de manuel bash (sous OS X 10.9):

Lorsqu'un shell interactif qui n'est pas un shell de connexion est démarré, bash lit et exécute les commandes à partir de ~ / .bashrc, si ce fichier existe. Cela peut être inhibé en utilisant l'option --norc. L'option --rcfile file forcera bash à lire et à exécuter les commandes à partir du fichier au lieu de ~ / .bashrc

Le texte ci-dessus est la raison pour laquelle tout est mis en .bashrc. Cependant, le comportement est légèrement différent lorsque vous utilisez un shell de connexion. Encore une fois, citant la page de manuel:

Lorsque bash est appelé en tant que shell de connexion interactif ou en tant que shell non interactif avec l'option --login, il lit et exécute d'abord les commandes du fichier / etc / profile, si ce fichier existe. Après avoir lu ce fichier, il recherche ~ / .bash_profile, ~ / .bash_login et ~ / .profile, dans cet ordre, et lit et exécute les commandes du premier qui existe et est lisible. L'option --noprofile peut être utilisée lorsque le shell est démarré pour empêcher ce comportement.

.profile est lu pour les shells de connexion, mais .bashrc n'est pas. Dupliquer toutes ces choses dans .bashrc est mauvais, nous devons donc le trouver dans .profile afin que le comportement reste cohérent.

Cependant, vous ne voulez pas vous procurer de source .bashrc de .profile inconditionnellement. S'il vous plaît voir les commentaires et autres réponses pour plus de détails.


-1



-1, NE PAS la source .bashrc de .profile. Voir la réponse de @ DanRabinowitz. - nyuszika7h
Au moins pas inconditionnellement. - nyuszika7h
[ -n "$BASH" -a -f ~/.bashrc ] && . ~/.bashrc serait un doux oneliner pour .profile. - John WH Smith
@ nyuszika7h, pourquoi pas? Tout le monde semble suggérer de le faire. - Pacerier