Forum Linux.général .bashrc sert à quoi ?

Posté par  .
Étiquettes : aucune
0
16
oct.
2009
Bonjour, je voudrais l'avis de ceux qui ont l'habitude d'ajouter des choses dans leur .bash_profile ou leur .bashrc : qu'est-ce qu'on met dans le second ?

Je sais quand ils sont utilisés et comment, je me demande juste pourquoi on considère en général que l'environnement va dans le premier, et les alias et les fonctions dans le second : qu'est-ce qu'on gagne à recharger tout ce qu'il y a dans .bashrc à chaque nouveau bash, qu'est-ce qu'on peut faire de plus qu'en chargeant tout une fois pour toutes au login ?

Et un autre truc, mon /etc/bash/bashrc était chargé deux fois au login jusque là, une fois via /etc/profile et une fois via .bash_profile ; j'ai enlevé le premier "source" parce qu'à chaque connexion dans un terminal virtuel le $PS1 semblait se comporter anormalement (un "user@machine" parasite sans couleurs s'ajoutait avant le $PS1 personnalisé). Est-ce qu'il y a un usage "propre" pour ça ?
  • # Shells de login

    Posté par  . Évalué à 6.

    Je sais quand ils sont utilisés et comment, je me demande juste pourquoi on considère en général que l'environnement va dans le premier, et les alias et les fonctions dans le second : qu'est-ce qu'on gagne à recharger tout ce qu'il y a dans .bashrc à chaque nouveau bash, qu'est-ce qu'on peut faire de plus qu'en chargeant tout une fois pour toutes au login ?

    Ces fichiers de config' ne servent pas seulement à définir des variables d'environnement : ils peuvent servir à lancer des commandes, également. D'autre part, bash fait le distingo entre les shells de login, les shells interactifs et les shells non interactifs, instanciés automatiquement quand tu lances un script, par exemple.

    Si je ne me trompe pas, .bashrc est lu par défaut chaque fois que bash est lancé (sauf options spéciales, ou invocation par sh, je crois), et .bash_profile est lu en plus à l'ouverture d'un shell de login.

    Mais comme je ne pratique pas souvent, le mieux est encore de revoir man bash.
    • [^] # Re: Shells de login

      Posté par  . Évalué à 1.

      Certes, j'ai lu la man... comme je l'ai dit dans mon message, ce que je cherche c'est un exemple concret de fonction ou d'alias ayant une raison de pas aller dans bash_profile. Presque tout ce que je lis sur internet énonce la règle mais l'explique pas.
      En fouillant un peu, je me suis rendu compte qu'à une époque kdm ne lançait pas de shell de login (vu que la syntaxe dépend du shell choisi) mais un shell normal ; ça n'a plus l'air d'être le cas, donc à part pour mettre des alias qu'on va tester dans la foulée en ouvrant un nouvel onglet de la console comme le suggère nodens, je vois toujours pas l'intérêt d'avoir les deux.
      Donc tant pis, je vais continuer à faire comme l'indiquent les écritures, il doit y avoir une raison.
      • [^] # Re: Shells de login

        Posté par  . Évalué à 2.

        C'est parce que tu considères toujours que les fichiers de conf' ne contiennent que des aliases, des variables d'environnement ou des définitions de fonctions. Mais ce sont d'authentiques scripts shell qui peuvent également appeler des commandes.

        D'autre part, un shell est instancié chaque fois qu'un script est lancé. Il est donc tout-à-fait possible −  dans le cas de /etc/init.d, par exemple − qu'ils soient lancés en dehors de toute session. Un script shell n'est pas forcément le père d'un autre shell. Cas plus précis encore, une instance d'un shell peut être la fille d'un shell différent. Si ces scripts sont quand même lancés sous ton identité, c'est ton ~/.bashrc qui sera interprété, même si tu n'es pas logué.

        Avant de donner des exemples concrets, il faut donc se souvenir que « profile » est attaché à la notion de login et « *rc » à l'instanciation d'un shell en général. Maintenant, les choses qui peuvent être intéressantes à redéfinir à chaque shell peuvent être, par exemple :

        - Le titre de la fenêtre, pour y coller le PID, entre autres. Voir http://linuxfr.org/forums/47/24650.html ;
        - Des définitions de fonctions ou de variables en fonction du contexte. La variable « $$ », qui donne le PID du shell en cours, est typiquement un truc qui serait défini dans .bashrc si le shell ne le faisait pas tout seul ;
        - etc.

        Et un autre truc, mon /etc/bash/bashrc était chargé deux fois au login jusque là, une fois via /etc/profile et une fois via .bash_profile ; j'ai enlevé le premier "source" parce qu'à chaque connexion dans un terminal virtuel le $PS1 semblait se comporter anormalement (un "user@machine" parasite sans couleurs s'ajoutait avant le $PS1 personnalisé). Est-ce qu'il y a un usage "propre" pour ça ?

        Il faut vérifier dans quel ordre sont exécutés tous ces fichiers de conf. Chez moi, c'est :

        /etc/profile
        /etc/bashrc
        ~/.bashrc
        ~/.bash_profile

        Il se peut qu'un de tes fichiers étende ta variable plutôt que de la redéfinir. Par exemple, « export PS1="\u@\h$PS1".
  • # en ce qui me concerne...

    Posté par  . Évalué à 3.

    J'utilise le .bashrc pour lancer, effectivement, des commandes qui doivent être à jour à chaque instance du shell. Des truc fondamentaux et indispensables comme fortune, par exemple.

    J'y mets aussi, plus sérieusement, tout ce que je risque de changer de temps en temps (pas besoin de se relogguer).

    Enfin, j'ai tendance à inclure d'autres fichiers dans mon .bashrc : si ils sont présent, j'inclus .bash_functions et .bash_aliases. Je réserve le .bashrc aux variables d'environnement, et aux aliases / fonctions que j'utilise partout (je distribue mon .bashrc sur plusieurs machines).
  • # variables et programmes

    Posté par  (site web personnel) . Évalué à 2.

    Personnellement j utilise bashrc et profile pour positionner des nouvelles variables d e'environnement. Comme je suis feignant et que mes variables n ont de variables que le nom, j utilise skel pour la plupart.

    Pour les programmes à lancer en début de session je préfère utiliser la norme freedesktop dans xdg/autorun, pour la plupart.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.