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

Ceci est gênant, mais après de nombreuses années d'utilisation des systèmes POSIX temps plein, il me reste encore du mal à comprendre si une personnalisation du shell devrait aller .bashrc, .profileou ailleurs. Sans parler de certains fichiers de configuration spécifiques au système d'exploitation, tels que .pam_environment.

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

TL; DR:

• ~/.bash_profiledevrait être super-simple et juste charger .profileet .bashrc(dans cet ordre)

• ~/.profilecontient des éléments non spécifiquement liés à bash, tels que des variables d'environnement ( PATHet des amis)

• ~/.bashrca tout ce que vous voulez sur une ligne de commande interactive. Invite de commande, EDITORvariable, alias bash pour mon utilisation

Quelques autres notes:

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

• ~/.bashrc ne doit rien sortir

• Tout ce qui ne devrait être disponible que pour les coquilles de connexion devrait aller dans ~/.profile

• Assurez-vous que cela ~/.bash_loginn'existe pas.

Au cours des dernières années, j'ai eu beaucoup de temps à perdre et j'ai donc effectué des recherches pendant un peu plus de 10 minutes. Je n'ai aucune idée si c'est la meilleure mise en page, c'est juste une qui fonctionne correctement dans à peu près tous les cas.

Les exigences:

• ~/.profile doit être compatible avec n’importe quel / bin / sh - cela inclut bash, dash, ksh, tout ce que la distribution pourrait choisir d’utiliser.

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

• Il y a très peu d'intérêt d'avoir les deux ~/.profile et ~/.bash_profile. Si ce dernier est manquant, bash l'utilisera avec plaisir, et toutes les lignes spécifiques à Bash peuvent être protégées par un contrôle de $BASHou $BASH_VERSION.

• La séparation entre *profileet *rcconsiste en ce que le premier est utilisé pour les shells de «connexion», et le second à chaque fois que vous ouvrez une fenêtre de terminal. Cependant, bash en mode 'login' ne génère pas ~/.bashrc, il ~/.profilefaut donc le faire manuellement.

La configuration la plus simple serait:

• Avoir un ~/.profileensemble qui définit toutes les variables d’environnement (à l’exception de celles spécifiques à bash), affiche éventuellement une ligne ou deux, puis les sources ~/.bashrcs’il est exécuté par bash, en respectant la syntaxe compatible sh.

  export TZ = "Europe / Paris"
  export EDITOR = "vim"
  si ["$ BASH"]; ensuite
      . ~ / .bashrc
  Fi
  la disponibilité
  

• Ayez un programme ~/.bashrcqui exécute n'importe quelle configuration spécifique au shell, protégé avec une vérification du mode interactif pour éviter de casser des choses comme sftpsur Debian (où bash est compilé avec l'option de chargement ~/.bashrcmême pour les shells non interactifs):

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

Cependant, il y a aussi le problème que certaines commandes non interactives (par exemple ssh <host> ls) sautent ~/.profile, mais les variables d'environnement leur seraient très utiles.

• Certaines distributions (par exemple, Debian) compilent leur bash avec l’option de source ~/.bashrcpour de telles connexions non interactives. Dans ce cas, il m'a été utile de déplacer toutes les variables d'environnement (les export ...lignes) dans un fichier séparé ~/.environet de le générer à partir des deux .profile et .bashrc, avec une protection, pour éviter de le faire deux fois:

  si ! ["$ PREFIX"]; puis    # ou $ EDITOR, ou TZ $, ou ... 
      . ~ / .environ            # généralement toute variable définie par .environ elle-même
  Fi
  

• Malheureusement, pour d'autres distributions (par exemple Arch), je n'ai pas trouvé de très bonne solution. Une possibilité consiste à utiliser le module PAM (activé par défaut) de pam_env, en mettant les éléments suivants dans ~/.pam_environment:

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

  Ensuite, bien sûr, mise ~/.environà jour vers 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 une immense douleur dans le cul.

Jetez un coup d'œil à cet excellent article de ShreevatsaR . Voici un extrait, mais consultez l'article du blog, qui inclut une explication de termes tels que "shell de connexion", 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. B1, B2, B3 signifie qu’il n’exécute que le premier des fichiers trouvés.

+----------------+-----------+-----------+------+
|                |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      |           |      |
+----------------+-----------+-----------+------+

Je vous propose mes directives "complètes":

• Marque .bash_profileet .profilecharge .bashrcsi elle existe, en utilisant par exemple [ -r $HOME/.bashrc ] && source $HOME/.bashrc
• Mettez tout le reste dans .bashrc.
• Cesse de t'inquieter.
• Tous les quatre ans environ, consacrez une dizaine de minutes à la recherche de cette question avant d'abandonner et de revenir à "ne vous inquiétez pas".

EDIT: Ajout de citations d'effarouchement à «complet» au cas où quelqu'un serait tenté de le croire. ;)

J'ai renoncé à essayer de comprendre celui-ci et ~/.shell-setupj'ai créé un script ( ) que je tire de tous les autres.

Cette approche nécessite ~/.shell-setupdeux fonctionnalités:

1. N'exécutez qu'une seule fois, même si les sources sont utilisées à plusieurs reprises (utilisez les protections Inclure )
2. Ne générez aucune sortie indésirable (détectez quand la sortie est correcte)

# 1 est assez standard, bien que peut-être peu utilisé dans les scripts shell.

# 2 est plus compliqué. 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é à cela, ni pourquoi la détection d'un shell interactif n'était pas suffisante.

Tout mettre dans .bashrcpuis source .bashrcde.profile

Depuis la page de manuel de 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 de ~ / .bashrc, si ce fichier existe. Cela peut être inhibé en utilisant l'option --norc. L'option de fichier --rcfile forcera bash à lire et à exécuter les commandes depuis le fichier au lieu de ~ / .bashrc

Le texte ci-dessus est la raison pour laquelle tout est mis en .bashrcpo Cependant, le comportement d'un shell de connexion est légèrement différent. 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 commence par lire et exécuter 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, puis lit et exécute les commandes à partir de la première qui existe et est lisible. L'option --noprofile peut être utilisée au démarrage du shell pour empêcher ce comportement.

.profileest lu pour les coquilles de connexion, mais .bashrcn'est pas. La duplication de tout ce que cela contient .bashrcest mauvaise ™, nous devons donc le rechercher .profileafin que le comportement reste cohérent.

Cependant, vous ne voulez pas la source .bashrcde .profilemanière inconditionnelle. Veuillez consulter les commentaires et autres réponses pour plus de détails.