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

30

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?

terdon
la source
Pourquoi serait -n "$BASH_VERSION"vrai en dehors de bash?
Elliott Frisch
@ElliottFrisch ce ne sera pas. Ma question est de savoir pourquoi le .profilesource .bashrc, ce n'est pas le cas dans toutes les versions de Linux et je me demande quelle est la raison derrière cela.
terdon
Semble être implémenté de cette façon dans Debian en amont.
Elliott Frisch
@ElliottFrisch oui, je pensais que ce n'était pas le cas et je l'ai regardé et j'ai vu qu'il était temps de modifier mon commentaire. Néanmoins, ce n'est pas le cas sur un système SuSe auquel j'ai accès (bien que ce soit sur un CentOS) et ce n'était pas le cas sur divers systèmes (RH, Fedoras, Ubuntus plus anciens) pour autant que je m'en souvienne. Je me demande donc pourquoi.
terdon

Réponses:

15

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.

terdon
la source
Je pense toujours que ce n'est pas une bonne idée. L'idéal serait de s'assurer que le gestionnaire d'affichage fournira un profil global (vérification) et le shell utilisateur .profile. Maintenant, je sais pourquoi j'ai des chemins dupliqués dans certaines variables ...
Rmano
2

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.

souravc
la source
Merci, ce sont toutes des informations vraies et utiles. Cela ne répond tout simplement pas à ma question. Je connais les différences entre les shells de connexion et non-login. Ma question est pourquoi, sur les systèmes Ubuntu, le .profilesourcing .bashrc? SuSe Enterprise 10 ne le fait pas, ni aucune des versions de Fedora que j'ai utilisées mais c'était il y a des années, je me trompe peut-être. CentOS 5.8 fait assez bizarrement. Quoi qu'il en soit, vous voyez mon point? C'est un choix de design et je me demande pourquoi il a été fait.
terdon
Je n'ai pas utilisé rigoureusement les autres distributions Linux que vous avez nommées. pouvez-vous me dire comment ils gèrent des situations comme les commandes aliasées dans une session ssh qui sont définies dans .bashrcou dans .bash_aliases. Par exemple, j'ai un alias pour lscomme ls --color=autodans mon .bashrcet mon .bashrcobtenu à partir de mon .profile. Ici, je peux utiliser l'alias même de ssh. Ou je pourrais utiliser un proxy dans une session ssh. Si je ne lit pas mon .bashrcde .profileje lâche ces caractéristiques. Je pense qu'il s'agit d'une meilleure expérience utilisateur.
souravc
Ils ne le font pas, ces alias ne fonctionneront pas. Et oui, l'approvisionnement .bashrccorrige cela. Mais cela cause aussi des problèmes, je me souviens de la première fois que j'ai utilisé un système qui avait ce comportement, je n'arrêtais pas de recevoir ces messages étranges quand sshj'y entrais parce que j'utilisais xset b offdans mon .bashrcqui avait l'habitude de désactiver la cloche du terminal mais seulement dans un système X donc il donnait des messages d'erreur. Cela m'a pris beaucoup de temps pour comprendre ce qui se passait, car je ne pensais pas que cela .bashrcserait lu lors de l'exécution d'un shell de connexion. Je me demande simplement s'il y a une déclaration "officielle" à ce sujet.
terdon
Je suis d'accord avec toi. J'ai également rencontré des problèmes plus tôt . Mais il est surtout utile et convivial, si vous gardez à l'esprit et évitez quelques cas particuliers. N'est-ce pas :)
souravc
Oui, il y a des raisons valables à cela. J'étais simplement curieux de savoir si Canonical avait jamais donné sa justification pour garder cette décision en amont.
terdon