Qu'est-ce que le fichier .bashrc ?

En fait, c'est bash spécifiquement qui se lit .bashrc (et /etc/bash.bashrc). Il existe de nombreux shells différents.

La page de manuel de bash (par Brian Fox et Chet Ramey ; également page d'info “Bash Startup Files” ) est la référence faisant autorité :

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

Lorsque bash est lancé de manière non interactive, pour exécuter un script shell, par exemple, il recherche la variable BASH_ENV dans l'environnement, développe sa valeur si elle y apparaît, et utilise la valeur développée comme nom de fichier à lire et à exécuter. Le Bash se comporte comme si la commande suivante était exécutée :

if [-n "$BASH_ENV"]; then . "$BASH_ENV"; fi

mais la valeur de la variable PATH n'est pas utilisée pour rechercher le nom du fichier.

Le fichier n'est que des commandes shell. Il est généralement utilisé pour modifier les invites, définir les variables d'environnement et les procédures shell. Traditionnellement, le fichier .profile est utilisé à cette fin, mais bash a tellement d'extensions qu'il a besoin de son propre fichier de démarrage pour les utilisateurs qui veulent mettre bashismes dans les fichiers de démarrage.

“Pas un shell de connexion” signifie des choses comme le lancement de scripts et généralement des fenêtres de terminal lancées par les gestionnaires de fenêtres. Parfois, je configure les systèmes *nix pour avoir .bashrc et BASH_ENV juste les sources .profile. Tant que vous ne vous écartez pas des commandes du shell POSIX, vous obtiendrez la même initialisation dans n'importe quel shell.

C'est particulièrement utile lorsque sh est vraiment bash, ce qui arrive parfois. Pour ce faire, utilisez :

. .profile

Une des raisons pour lesquelles tout cela est si complexe est que parfois les gens mettent des choses qui produisent une sortie dans les fichiers de démarrage de l'interpréteur de commandes, ou ils définissent inconditionnellement les invites. Cela cause beaucoup de problèmes lors de l'exécution de programmes shell et de commandes backtick dans les langages, sans parler de system(3) des programmes C. La façon dont bash démarre est conçue, je pense, pour avoir un fichier où la sortie et le paramétrage des invites sont corrects et un autre où ils ne le sont pas. Traditionnellement, un test d'exécution serait effectué pour distinguer l'interactivité, par exemple, en vérifiant si l'invite est définie.

Lorsque Bash démarre, il exécute les commandes dans une variété de scripts différents.

Lorsque Bash est invoqué comme un shell de connexion interactif, 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 fichier qui existe et qui est lisible.

Lorsqu'un shell de connexion se termine, Bash lit et exécute les commandes du fichier ~/.bash_logout, s'il existe.

Lorsqu'un shell interactif qui n'est pas un shell de connexion est lancé, Bash lit et exécute les commandes de ~/.bashrc, si ce fichier existe. Ceci peut être inhibé en utilisant l'option –norc. L'option –rcfile file forcera Bash à lire et à exécuter des commandes à partir du fichier au lieu de ~/.bashrc. http://en.wikipedia.org/wiki/Bash_(Unix_shell)

Voici quelques trucs et astuces : http://www.cyberciti.biz/tips/howto-linux-unix-bash-shell-setup-prompt.html

Essayons de régler l'invite pour qu'elle puisse afficher la date du jour et le nom d'hôte :

PS1="\d \h $ "

Il devrait contenir diverses commandes “d'initialisation” pour votre shell, par exemple :

• Création d'alias utiles (par exemple alias ll='ls -l').
• Ajout de répertoires supplémentaires à PATH.
• Définition de nouvelles variables d'environnement.