Les fichiers de configuration du shell

Un article de Wiki de la communauté Mandriva.

Jump to: navigation, search

CETTE PAGE EST UNE VERSION RÉVISÉE DE LA PAGE MAINTENANT OBSOLÈTE DE L'ANCIENNE BASE DE CONNAISSANCES :
http://club.mandriva.com/xwiki/bin/KB/ConfigShell ptyxs 9 mars 2008 à 11:55 (CET)



Sommaire

[modifier] Introduction

Je ne prétends pas du tout traiter ici de la totalité des questions posées par les fichiers de configuration du shell Bash sous Linux, mais seulement donner quelques éléments partiels qui valent pour mon système Mandriva Linux, dans son état actuel, et qui n'apparaissent pas toujours très clairement dans les diverses documentations…

Apparemment, dans d'autres distributions Linux, les choses peuvent être un peu différentes de ce qui est décrit ici.

Ce qui suit devrait vous aider à intervenir à bon escient sur votre système et vous permettre de modifier le contenu des fichiers de configuration en étant pleinement conscients de ce que vous faites.

[modifier] Différences entre les fichiers de configuration

Les fichiers de configuration du shell se distinguent de quatre façons (au moins) :


[modifier] Par les utilisateurs concernés

  • les uns valent pour tous les utilisateurs du système :
    • /etc/profile
    • /etc/bashrc
    • l'ensemble des fichiers dont les noms sont de la forme *.sh contenus dans le répertoire /etc/profile.d.
      A titre d'exemple, dans mon système, il s'agit de l'ensemble de fichiers suivants :
      10lang.sh alias.sh
      configure_keyboard.sh
      gconf.sh
      glib20.sh
      gnome-ssh-askpass.sh
      inputrc.sh
      jre-1.4.2_09.sh
      kde3.sh
      keychain.sh less.sh
      mc.sh
      menu-xdg.sh
      msec.sh
      python.sh
      qtdir3.sh
      screen.sh
      ssh-client.sh
      tmpdir.sh xhost.sh
    Toute modification apportée à l'un de ces fichiers vaut pour tout utilisateur du système.


  • d'autres sont propres à un utilisateur :
    • ~/.bash_profile
    • ~/.bashrc
    • ~/.bash_logout
    Les modifications apportées à ces fichiers ne concernent qu'un seul utilisateur (une modification de /home/toto/.bashrc n'aura de conséquence que pour l'utilisateur toto).
    Rappel : '~' représente le répertoire personnel d'un utilisateur, en fait la valeur de la variable $HOME, pour l'utilisateur toto on aura par défaut : '~' = /home/toto/.

[modifier] Par le type de shell qui les lit en démarrant


  • shell interactif ou shell non interactif
    Lorsque le shell exécute un script, il lit des lignes de code dans un fichier, il n'est pas alors, en général, 'à l'écoute' de ce que vous tapez en console : on dit dans ce cas que le shell est non interactif.
    Lorsque, au contraire, vous lancez des commandes pour le shell dans n'importe quelle console, vous êtes dans un shell interactif.
    Nous nous intéressons ici uniquement aux shells interactifs. Les fichiers de configuration que nous évoquons ne sont pas en général lus par les shells non interactifs.


Parmi les shells interactifs, on doit encore distinguer :


  • shell de connexion (en anglais login shell) ou shell sans connexion (non login shell)
    Le shell varie à cet égard selon le type de la console dans laquelle vous l'invoquez. Il faut distinguer :
    • Les consoles tty
    Elles sont ainsi appelées parce qu'elles correspondent dans le répertoire /dev à des fichiers spéciaux /dev/ttyn (où n est un nombre), pour mémoire  : tty vient du mot TeleTYpe. Ces consoles, qu'on appelle aussi parfois consoles texte sont celles sur lesquelles vous vous rendez par les combinaisons de touches <CTRL-ALT-F1> à <CTRL-ALT-F6>.

    Pour exécuter une commande sur de telles consoles vous devez d'abord vous connecter (vous loguer) en tapant votre nom d'utilisateur (le login) et votre mot de passe.

    Les shells que vous exécutez alors sont des shells de connexion (login shells).
    • Les consoles graphiques
    Ce sont celles que vous invoquez à partir de votre environnement X (autrement dit sous KDE, GNOME, IceWM...) quand vous lancez des utilitaires tels que Konsole, xterm, rXVT etc.
    Dans /dev, ces consoles sont représentées par des fichiers /dev/pts/nn est un nombre (pts pour pseudo-terminaux= pseudo-terminals en anglais).

    Lorsque vous ouvrez une telle console vous n'avez pas à vous connecter, à fournir login et mot de passe.

    Les shells qui interprètent des commandes lancées sur de telles consoles sont donc des shells sans connexion (non login shells).


Rappel : Les shells interactifs peuvent être des login shells ou des non login shells.


Parmi les fichiers de configuration mentionnés plus haut, les suivants ne sont lus QUE par des login shells :

  • /etc/profile
  • ~/.bash_profile
  • ~/.bash_logout

Les deux premiers sont lus juste après la connexion et le dernier juste avant la déconnexion.

Toute modification que vous y introduirez ne sera donc d'aucun effet lorsque vous vous contenterez d'ouvrir ou de relancer, immédiatement après avoir introduit la modification, une console graphique (du genre de l'utilitaire Konsole ou rxvt etc.), où les commandes que vous lancerez seront toujours lues par un non login shell. MAIS :

Attention !
Se connecter sous une interface graphique est assimilé à cet égard à se connecter sous une sorte particulière de console : et de ce fait les deux premiers fichiers, /etc/profile et ~/.bash_profile seront lus dès la connexion à une interface graphique. En revanche, ~/.bash_logout ne semble pas être lu à la déconnexion de l'interface graphique.


Tous les autres fichiers mentionnés plus haut (/etc/bashrc ou ~/.bashrc et les fichiers *.sh de /etc/profile.d) sont, en revanche, lus et par les login shells et par les non login shells : toute modification que vous y introduirez vaudra donc quelle que soit la console que vous utiliserez.

[modifier] Par le fait que le shell concerné est lui-même ou non un processus enfant d'une autre instance du shell

Les fichiers /etc/profile et ~/.bash_profile ne sont lus qu'au premier lancement d'un login shell, si ensuite Bash s'appelle lui-même et lance un 'shell enfant' ces fichiers ne sont pas lus une seconde fois. Au contraire /etc/bashrc et ~/.bashrc sont lus à chaque nouvel appel du shell.

Notez que ceci est tout à fait naturel : lorsque le login shell lance une nouvelle session du shell (par exemple, quand vous tapez la commande bash), votre login ne vous est pas redemandé : l'enfant d'un login shell ne se comporte donc pas lui-même comme un login shell...

De même, ~/.bash_logout est lu en fin de connexion par un login shell qui n'est pas lui-même enfant d'un autre shell : il est donc lu au moment où vous quittez le shell complètement (et en général il va servir simpement à effacer le contenu de l'écran).

/etc/profile et ~/.bash_profile sont AUSSI lus silencieusement au moment ou le serveur X lance une session (au démarrage de KDE, par exemple). De ce fait, les initialisations de variables qu'ils contiennent sont disponibles sous les consoles graphiques, bien que les shells qui sont attachés à ces consoles ne lancent pas eux-mêmes ces deux fichiers en démarrant.

[modifier] Par la variété de shell utilisée

Tous les fichiers de configuration dont il est question ici sont lisibles par un shell Bash mais tous ne le sont pas par d'autres types de shells, attention, pensez donc à vérifier ce qu'il en est si vous avez recours à d'autres sortes de shells (Korn shell, C-shell etc.).


[modifier] Comment se rendre compte de tout cela par soi-même

Pour bien vous rendre compte de tout cela un moyen très intuitif consiste à modifier chacun des fichiers :

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

de la façon suivante : mettre au tout début de chaque fichier une ligne de ce type

echo /chemin/nom_du_fichier DEBUT

et en dernière ligne ceci :

echo /chemin/nom_du_fichier FIN

(naturellement vous mettrez à la place de /chemin/nom_du_fichier l'information appropriée pour chaque fichier, par exemple /etc/profile pour le premier fichier, /home/toto/.bash_profile pour le second si votre nom d'utilisateur est toto etc.).


Dans le cas particulier de ~/.bash_logout utilisez la commande sleep pour avoir le temps de voir vraiment ce qui se passe et écrivez ces lignes en fin de fichier :


echo /home/toto/.bash_logout
sleep 5 


Ensuite, lancez le shell, dans une console tty, puis dans une console graphique. Relancez-le plusieurs fois par des commandes bash successives (tapez bash puis <ENTREE>, ce qui lancera un processus shell enfant), puis sortez par des commandes exit successives, jusqu'à ce que vous vous retrouviez dans l'état initial, regardez bien tout ce qui s'affiche et vérifiez que cela illustre ce qui a été dit plus haut… Passez sous root et voyez (très prudemment) ce qui se passe en console lorsque vous effectuez le même genre d'essais que précédemment.


Pour tester ce qui se passe lorsque vous ne disposez pas de console pour voir un message envoyé par la commande echo, par exemple au moment de la connexion ou de la déconnexion du serveur X, vous devez procéder autrement. Une moyen bien simple consiste à ajouter comme dernière ligne du fichier de configuration qui vous intéresse, une commande qui crée un fichier vide, quelque chose comme touch /home/toto/lefichdessai, vous pourrez déterminer ensuite, selon que le fichier lefichdessai aura été créé ou pas, si le fichier de configuration a été ou non exécuté.

[modifier] Qui lance quoi ?

En lisant le contenu des scripts, comme en examinant les messages affichés par les lignes de commande echo ou touch que vous avez ajoutées à la section précédente, vous verrez que, sous la Mandriva :


  • A la connexion, sont lancés successivement : /etc/profile, puis ~/.bash_profile


  • ~/.bash_profile lance ~/.bashrc
  • ~/.bashrc lance /etc/bashrc.


  • Les fichiers *.sh de /etc/profile.d sont lancés dans les shells de connexion par /etc/profile et dans les shells sans connexion par /etc/bashrc, ils sont donc toujours lancés au démarrage d'un shell, que le shell soit login ou non login et qu'il soit ou non enfant d'une autre instance du shell.


Si vous souhaitez définir des alias pour tous les utilisateurs, pensez donc à utiliser /etc/profile.d/alias.sh.


Attention !
Etant donné que /etc/profile, puis ~/.bash_profile sont exécutés à chaque connexion au serveur X, il s'ensuit que ~/.bashrc puis /etc/bashrc le sont aussi. Et c'est là que vous voyez que ces « fichiers de configuration du shell Bash » jouent un rôle considérable puisqu'ils sont aussi exécutés chaque fois que vous lancez votre interface graphique... (en toute rigueur : je n'ai vérifié cela que sous KDE).

[modifier] Que mettre dans ces fichiers ?

Vous pouvez personnaliser différents aspects de votre système en modifiant les fichiers de configuration dont nous venons de parler. Pour plus de détails, cliquez sur les rubriques ci-dessous qui énumèrent quelques possibilités.

Dans les fichiers de configuration vous pouvez :

  • définir des alias
  • définir des fonctions
  • fixer la valeur de certaines variables (notamment la variable PATH, qui dit aux système où il peut trouver les commandes à lancer et la variable PS1, qui personnalise l'invite du shell, si vous utilisez Java, vérifiez que la valeur de la variable $HOME_JAVA, qui contient le chemin du répertoire de Java, est correctement fixée dans le fichier /etc/profile/jre-<version>.sh)
  • vous pouvez même lancer des commandes...

[modifier] Un mot sur inputrc

Un autre fichier de configuration est important pour le shell : le fichier /etc/inputrc qui configure la bibliothèque Readline, laquelle est utilisée par le shell pour l'interprétation des touches ou combinaisons de touches du clavier.

Pour un exemple de configuration personnalisée d'inputrc, voir root#su -c. Sur des indications pour configurer inputrc, voir cette page de la Gazette Linux - Comment créer des raccourcis clavier sur les consoles Linux.

Attention, n'essayez pas d'introduire des commandes echo dans ce fichier : les messages ne s'afficheraient pas et Readline tenterait de comprendre les lignes de code que vous auriez ajoutées comme des commandes d'interprétation du clavier qui perturberaient son bon fonctionnement.

Le fichier inputrc contient essentiellement :

  • des lignes du type set machin on ou set machin off qui activent ou désactivent, respectivement, une certaine fonctionnalité machin (vous trouverez la liste de ces fonctionnalités dans la section Variables de cette page)
  • des lignes de la forme "chaîne": machin (attention aux guillemets !) qui disent que la chaîne de caractères chaîne correspondra désormais à la commande machin (vous trouverez la liste de ces commandes dans la section Editing commands de cette page)
  • des lignes de la forme "chaîne": "autre_chaîne" (attention aux guillemets !) qui disent que la chaîne de caractères chaîne doit être remplacée par autre_chaîne.

Dans les deux derniers cas, les caractères à gauche des deux-points sont ceux que renvoient les touches du clavier de façon ordinairement « invisible ». Pour connaître les caractères renvoyés par une certaine touche, il suffit de taper Ctrl-V (ou Ctrl-Q) suivi de la touche en question. Il faut en outre savoir que Ctrl est représenté dans inputrc par \C et que la suite ^[ (envoyée notamment par la touche Echap) est abrégée en \e. Illustrons : sous Konsole, si vous faites Ctrl-V FIN (il s'agit ici de Contrôle+V suivi de la touche FIN), vous obtenez à l'écran ^[[F, ce qui montre qu'il s'agit là de la chaîne de caractères envoyée par la touche FIN. Nous pouvons comprendre maintenant, par exemple, la ligne suivante, qui se trouve dans mon inputrc :

"\e[F": end-of-line

étant donné que \e remplace ^[ cette ligne équivaut à ^[[F': end-of-line et comme nous savons que ^[[F représente ce que renvoie la touche FIN, il s'ensuit que cette ligne signifie simplement que la touche FIN doit activer la fonction end-of-line, c'est-à-dire la fonction aller en fin de ligne.

Noter enfin que, selon les types de console, les caractères renvoyés par certaines touches peuvent différer, par exemple la touche FIN renvoie, comme nous l'avons vu, ^[[F sous Konsole mais ^[[8~' sous rXVT.

/etc/inputrc régit l'ensemble des utilisateurs de votre système, si nécessaire vous pouvez créer un fichier '/.inputrc pour un utilisateur particulier.

Muni de ce bagage substantiel, vous pourrez maintenant explorer et éventuellement modifier votre' 'inputrc

[modifier] L'historique des commandes

Le fichier ~/.bash_history contient une liste des commandes précédemment tapées en console. Pour l'utilisation de cette fonctionnalité et des indications permettant de la paramétrer voir l'historique du shell et suivre les différents liens que vous y trouverez.

[modifier] Modifier l'affichage du contenu d'un répertoire par ls

Les couleurs et divers aspects de l'affichage à l'écran de la sortie de ls sont déterminés par le fichier de configuration /etc/DIR_COLORS pour l'ensemble du système et par ~/.dir_colors pour un utilisateur.

Voir là-dessus : Le shell sans peine#Comment modifier les couleurs des listes de fichiers affichées par ls ?.

[modifier] Précautions à prendre lors de modifications de fichiers de configuration

Quelques remarques de bon sens, mais très importantes :


1) Ne faites pas 'n'importe quoi', renseignez-vous aux meilleures sources avant d'agir

2) Si vous voulez faire toute une série de modifications, procédez étape par étape, introduisez une modification, testez-la avec soin et ensuite seulement passez à la suivante

3) Commencez par sauvegarder le fichier dans son état originel en lui donnant un nom facile à repérer (du genre nom_de_fichierVieux)

4) Faites en sorte de pouvoir retrouver très facilement vos modifications. Une façon de faire : si vous insérez une ligne faites-la suivre d'un commentaire avec vos initiales, vous pourrez la retrouver très facilement par inspection visuelle du fichier ou avec une fonction de recherche de votre éditeur de texte, pour Toto Dugommier, une ligne de code blablabla ajoutée sera :

blablabla #TD

Procédez de la même façon pour une modification d'une ligne existante en indiquant en commentaire la nature du changement. Enfin si vous voulez désactiver une ligne mettez un commentaire devant plutôt que de l'effacer, pour la ligne bliblibli cela donnera :

# bliblibli #TD

Pour le shell Bash les commentaires sont précédés d'un dièse (#), pour certains autres fichiers de configuration du système les commentaires peuvent être codés différemment, pensez-y à l'occasion...

Ayez une politique sérieuse et systématique de sauvegarde (pensez, par exemple, à utiliser Unison).


Si vous suivez systématiquement ces procédures, vous resterez maître de la situation… sinon… j'en frissonne…

[modifier] Lors d'une mise à jour

Beaucoup d'installations possèdent une partition racine pour le système (/) et une autre partition pour les comptes utilisateur (/home). Vérifiez si c'est le cas pour votre système à l'aide de la commande df. S'il en est ainsi, et si au moment d'installer une nouvelle version de Mandriva vous choisissez de ne mettre à jour, ou de réinstaller, que la partition racine en laissant intacte la partition /home, alors, après mise à jour vous conserverez les modifications que vous aviez introduites dans les fichiers de configuration utilisateur (ceux dont les chemins commencent par ~/), mais vous perdrez les modifications effectuées sur les autres fichiers. Bien entendu vous ne les perdrez pas vraiment, car je ne vous ferai pas l'injure de penser que vous avez oublié de faire une sauvegarde générale avant la mise à jour… Vous pourrez donc ouvrir les anciens fichiers système et rapatrier vos anciennes modifications sur les nouveaux fichiers de configuration. Mais attention ! ne faites surtout pas un copier-coller général de l'ancien fichier vers le nouveau car, dans la nouvelle version, Mandriva a très bien pu modifier les fichiers de configuration système !! Ne recopiez que vos modifications, si elles vous conviennent encore, et tout ce qui a été dit plus haut reste valable : sauvegardez le fichier originel, faites en sorte de pouvoir retrouver facilement vos modifications à l'intérieur du fichier, et réintroduisez-les progressivement en les testant, car dans le nouveau système, on ne peut exclure que certaines d'entre elles aient des conséquences différentes… Prudence donc, comme toujours, lorsqu'on modifie les fichiers qui gèrent l'ensemble du système.