240 votes

Choisir entre .bashrc, .profile, .bash_profile, etc.

C'est embarrassant, mais après de nombreuses années d'utilisation de systèmes POSIX à plein temps, j'ai encore du mal à savoir si une personnalisation Shell doit aller dans .bashrc , .profile ou ailleurs. Sans parler de certains fichiers de configuration spécifiques au système d'exploitation, tels que .pam_environment .

Oui, je sais comment lire la documentation et apprendre quand chaque fichier est ou n'est pas chargé. Ce que je me demande, c'est si quelqu'un a déjà établi des directives complètes sur la façon de décider dans quel fichier placer un type de personnalisation donné.

8 votes

Cette question ne devrait pas être marquée comme dupliquée, la raison étant que le profil n'est pas disponible dans la question ajoutée.

0 votes

272voto

Dan Rabinowitz Points 2661

TL;DR :

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

  • ~/.profile a le truc PAS spécifiquement liés à bash, comme les variables d'environnement ( PATH et amis)

  • ~/.bashrc a tout ce que vous voulez sur une ligne de commande interactive. Invite de commande, EDITOR variable, 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 produire

  • Tout ce qui ne doit être accessible qu'aux shells de connexion doit être placé dans le dossier de l'utilisateur. ~/.profile

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

66voto

James Mertz Points 390

Ces dernières années, j'ai eu beaucoup de temps à perdre, alors j'ai ont faites-le pendant un peu plus de 10 minutes. Je n'ai aucune idée si c'est la meilleure disposition, c'est juste celle qui fonctionne correctement dans presque tous les cas.

Les exigences :

  • ~/.profile doit être compatible avec n'importe quel /bin/sh - cela inclut bash, dash, ksh, et tout ce qu'une distro pourrait choisir d'utiliser.

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

  • Il y a très peu d'intérêt à avoir les deux ~/.profile y ~/.bash_profile . Si ce dernier n'est pas présent, bash utilisera le premier, et toutes les lignes spécifiques à bash peuvent être protégées par une vérification pour $BASH o $BASH_VERSION .

  • La séparation entre *profile y *rc est que la première est utilisée pour les shells de "login", et la seconde à chaque fois que vous ouvrez une fenêtre de terminal. Cependant, bash en mode 'login' ne génère pas de code source. ~/.bashrc donc ~/.profile doit le faire manuellement.

El le plus simple la configuration serait :

  • Ayez un ~/.profile qui définit toutes les variables d'environnement (à l'exception de celles spécifiques à la base), imprime peut-être une ligne ou deux, puis génère des sources ~/.bashrc si elle est exécutée par bash, en respectant la syntaxe compatible avec sh sinon.

    export TZ="Europe/Paris"
    export EDITOR="vim"
    if \[ "$BASH" \]; then
        . ~/.bashrc
    fi
    uptime
  • Ayez un ~/.bashrc qui effectue toute configuration spécifique à Shell, gardé avec une vérification pour mode interactif pour éviter de casser des choses comme sftp sur Debian (où bash est compilé avec l'option de charger ~/.bashrc même pour les shells non interactifs) :

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

Cependant, il y a aussi 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 ces connexions non interactives. Dans ce cas, j'ai trouvé utile de déplacer toutes les variables d'environnement (l'élément export ... lignes) dans un fichier séparé, ~/.environ et de s'approvisionner auprès de les deux .profile y .bashrc avec un garde pour éviter de le faire deux fois :

    if ! \[ "$PREFIX" \]; then   _\# or $EDITOR, or $TZ, or ..._
        . ~/.environ           _\# generally any variable that .environ itself would set_
    fi
  • Malheureusement, pour d'autres distributions (par exemple Arch), je n'ai pas trouvé de très bonne solution. Une possibilité est d'utiliser le module PAM (activé par défaut) pam_env, en mettant ce qui suit dans le fichier ~/.pam_environment :

    BASH\_ENV=./.environ        _\# not a typo; it needs to be a path, but ~ won't work_

    Ensuite, bien sûr, la mise à jour ~/.environ a unset BASH_ENV .


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

44voto

Flimm Points 9047

Jetez un coup d'œil à ceci excellent blog post par ShreevatsaR . Voici un extrait, mais allez voir l'article du blog, il comprend une explication pour des termes comme "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 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      |           |      |
+----------------+-----------+-----------+------+

25voto

Mechanical Fish Points 383

Je vous propose mes directives "complètes" :

  • Faire .bash_profile y .profile charge .bashrc s'il existe, en utilisant par exemple [ -r $HOME/.bashrc ] && source $HOME/.bashrc
  • Mettez tout le reste dans .bashrc .
  • Arrêtez de vous inquiéter.
  • Tous les quatre ans environ, passez dix minutes à faire des recherches sur cette même question avant d'abandonner et de retourner à "ne pas s'inquiéter".

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

1voto

ShadSterling Points 1301

J'ai renoncé à essayer de résoudre ce problème et j'ai créé un script ( ~/.shell-setup ) que je source à partir de tous les autres.

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

  1. Ne s'exécute qu'une seule fois, même si la source est répétée (utiliser Inclure les gardes )
  2. Ne pas générer de sortie indésirable (détecter quand la sortie est correcte)

Le #1 est assez standard, bien que peut-être peu utilisé dans Shell Shell.

Le numéro 2 est plus délicat. Voici ce que j'utilise dans bash :

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

Malheureusement, je ne me rappelle pas comment j'ai trouvé ça, ni pourquoi. détection d'un Shell interactif n'était pas suffisant.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X