Pourquoi la source par défaut ~ / .profile d'Ubuntu ~ / .bashrc?

Voici le contenu du stock ~/.profilefourni avec mon 13.10 (lignes commentées supprimées):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

C'est hérité de Debian mais pourquoi Canonical a-t-il décidé de le garder? Pour autant que je sache, ce n'est pas la manière standard * nix et j'ai vu divers systèmes où cela ne s'est pas produit, donc je suppose qu'ils ont dû avoir une bonne raison. Cela peut provoquer un comportement inattendu lors de l'exécution de shells de connexion (comme lors de la saisie dans la machine par exemple) où l'utilisateur ne s'attendrait pas à avoir ~/.bashrcsourcé.

Le seul avantage auquel je peux penser est de ne pas confondre l'utilisateur avec de nombreux fichiers de démarrage et de leur permettre de les éditer .bashrcseuls et de les lire indépendamment du type de shell. Cependant, cela est un avantage douteux car il est souvent utile d'avoir des paramètres différents pour la connexion et pour les shells interactifs et cela vous empêche de le faire. De plus, les shells de connexion ne sont pas souvent exécutés dans un environnement graphique et cela peut provoquer des erreurs et des avertissements et des problèmes (oh mon Dieu!) En fonction de ce que vous avez défini dans ces fichiers.

Alors pourquoi Ubuntu fait-il cela, qu'est-ce qui me manque?

Il s'agit d'une décision en amont venant de Debian. La raison de cela est expliquée dans ce très joli article wiki , dont voici un extrait. Le résumé analytique est "pour garantir que les connexions GUI et non GUI fonctionnent de la même manière":

Prenons xdm comme exemple. Pierre revient un jour de vacances et découvre que son administrateur système a installé xdm sur le système Debian. Il se connecte très bien, et xdm lit son fichier .xsession et exécute fluxbox. Tout semble aller bien jusqu'à ce qu'il reçoive un message d'erreur dans le mauvais endroit! Puisqu'il remplace la variable LANG dans son .bash_profile, et comme xdm ne lit jamais .bash_profile, sa variable LANG est maintenant définie sur en_US au lieu de fr_CA.

Maintenant, la solution naïve à ce problème est qu'au lieu de lancer "xterm", il pourrait configurer son gestionnaire de fenêtres pour lancer "xterm -ls". Cet indicateur indique à xterm qu'au lieu de lancer un shell normal, il devrait lancer un shell de connexion. Sous cette configuration, xterm génère / bin / bash mais il place "- / bin / bash" (ou peut-être "-bash") dans le vecteur d'argument, donc bash agit comme un shell de connexion. Cela signifie que chaque fois qu'il ouvre un nouveau xterm, il lira / etc / profile et .bash_profile (comportement bash intégré), puis .bashrc (car .bash_profile dit de le faire). Cela peut sembler fonctionner correctement au début - ses fichiers de points ne sont pas lourds, donc il ne remarque même pas le retard - mais il y a un problème plus subtil. Il lance également un navigateur Web directement depuis son menu Fluxbox, et le navigateur Web hérite de la variable LANG de fluxbox, qui est désormais définie sur le mauvais paramètre régional. Ainsi, même si ses xterms peuvent être corrects, et tout ce qui est lancé à partir de ses xterms peut être correct, son navigateur Web lui donne toujours des pages dans le mauvais emplacement.

Alors, quelle est la meilleure solution à ce problème? Il n'y en a vraiment pas d'un universel. Une meilleure approche consiste à modifier le fichier .xsession pour qu'il ressemble à ceci:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

Cela provoque le shell qui interprète le script .xsession à lire dans / etc / profile et .bash_profile s'ils existent et sont lisibles, avant d'exécuter xmodmap ou xterm ou "exécuter" le gestionnaire de fenêtres. Cependant, il y a un inconvénient potentiel à cette approche: sous xdm, le shell qui lit .xsession s'exécute sans terminal de contrôle. Si / etc / profile ou .bash_profile utilise des commandes qui supposent la présence d'un terminal (comme "fortune" ou "stty"), ces commandes peuvent échouer. C'est la principale raison pour laquelle xdm ne lit pas ces fichiers par défaut. Si vous allez utiliser cette approche, vous devez vous assurer que toutes les commandes de vos "fichiers dot" sont exécutées en toute sécurité lorsqu'il n'y a pas de terminal.

C'est le comportement standard d'Ubuntu, ~/.bashrcc'est un fichier de démarrage au niveau de l'utilisateur par shell interactif. Lorsque vous ouvrez un terminal, vous démarrez un shell interactif sans connexion qui lit ~/.bashrcet lit le contenu ~/.bashrcobtenu et exporté dans votre environnement shell actuel. Il aide à obtenir toutes ses variables et fonctions de shell définies par l'utilisateur dans le shell actuel. Vous pouvez également trouver des lignes comme celle-ci

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

pour obtenir des alias définis par l'utilisateur dans l'environnement shell actuel.

Ceci est important pour offrir une bonne expérience utilisateur également. Par exemple , on pourrait stocker dans des titres de compétence proxy .bashrc, à moins qu'il ne se sourced aucune des applications de terminaux ( à savoir , ping, wget, curl, lynxetc.) fonctionnera correctement. Ou vous devez fournir les informations d'identification du proxy à chaque fois que vous ouvrez un terminal.

Outre la valeur par défaut d'Ubuntu, il .bashrccontient de nombreux alias conviviaux (pour lset greppour imprimer les sorties colorisées), de nombreuses nouvelles définitions pour différentes variables de shell, ce qui augmente l'expérience utilisateur.

Mais dans le cas de votre connexion ssh ou de votre connexion dans la console virtuelle , vous obtenez essentiellement un shell de connexion interactif. Le fichier d'initiation du shell est là ~/.profile. Par conséquent, à moins que ~/.bashrcvous ne recherchiez tous ces paramètres utiles dans votre .bashrc. C'est pourquoi la ~/.profilesource par défaut d'Ubuntu~/.bashrc

Cas à éviter

• vous ne devriez jamais chercher le ~/.profileformulaire à l'intérieur ~/.bashrcen même temps que celui d' ~/.bashrcorigine ~/.profile. Cela créera une boucle infinie de situation et par conséquent, votre invite de terminal sera suspendue à moins que vous n'appuyiez sur Ctrl+ C. Dans une telle situation, si vous mettez une ligne dans votre~/.bashrc

set -x

Ensuite, vous pouvez voir que le descripteur de fichier s'arrête lorsque vous ouvrez un terminal.