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

24

Ce sont les contenus du stock ~/.profile fourni 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

Ceci est hérité de Debian mais pourquoi Canonical a-t-il décidé de le conserver? 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 de le faire. Cela peut entraîner un comportement inattendu lors de l'exécution de shells de connexion (par exemple, lors de la connexion à la machine) où l'utilisateur ne s'attend pas à ce que ~/.bashrc soit source.

Le seul avantage auquel je peux penser est de ne pas confondre l’utilisateur avec de nombreux fichiers de démarrage et de lui permettre de modifier .bashrc seul et de le faire lire quel que soit le type de shell. Ceci, cependant, 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. En outre, les shells de connexion ne sont généralement pas exécutés dans un environnement graphique et peuvent entraîner des erreurs, des avertissements et des problèmes (oh!) En fonction de ce que vous avez défini dans ces fichiers.

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

    
posée terdon 11.03.2014 - 02:23
la source

2 réponses

12

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

  

Prenons par exemple xdm. Pierre revient de vacances un jour 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 être OK jusqu'à ce qu'il reçoive un message d'erreur dans la mauvaise région! Comme il remplace la variable LANG dans son fichier .bash_profile et que 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". Ce drapeau indique à xterm qu'au lieu de lancer un shell normal, il doit lancer un shell de connexion. Sous cette configuration, xterm spawns / 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 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 à partir de son menu fluxbox, et le navigateur Web hérite de la variable LANG de fluxbox, qui est désormais définie sur les paramètres régionaux incorrects. Donc, bien que ses xterms soient corrects et que tout ce qui est lancé à partir de ses xterms soit correct, son navigateur Web lui fournit toujours des pages dans des paramètres régionaux incorrects.

     

Quelle est la meilleure solution à ce problème? Il n'y a pas vraiment 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 la lecture par le shell interprétant le script .xsession dans / etc / profile et .bash_profile s'ils existent et sont lisibles, avant d'exécuter xmodmap ou xterm ou "d'exécuter" le gestionnaire de fenêtres. Cependant, cette approche présente un inconvénient potentiel: sous xdm, le shell qui lit .xsession s'exécute sans terminal de contrôle. Si / etc / profile ou .bash_profile utilise des commandes supposant la présence d'un terminal (tel que "fortune" ou "stty"), ces commandes peuvent échouer. C'est la raison principale pour laquelle xdm ne lit pas ces fichiers par défaut. Si vous envisagez d'utiliser cette approche, vous devez vous assurer que toutes les commandes de vos "fichiers de points" peuvent être exécutées en toute sécurité en l'absence de terminal.

    
réponse donnée terdon 17.03.2014 - 16:41
la source
1

Il s’agit du comportement standard d’Ubuntu, ~/.bashrc est un fichier de démarrage de niveau interactif par niveau utilisateur. Lorsque vous ouvrez un terminal, vous lancez essentiellement un shell interactif sans connexion . qui lit ~/.bashrc et le contenu de ~/.bashrc est généré et exporté dans votre environnement shell actuel. Cela aide à obtenir toutes les variables shell et 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, il est possible de stocker les informations d'identification du proxy dans .bashrc , à moins qu'elles ne proviennent de l'application de terminal ( viz , ping , wget , curl , lynx etc.) correctement. Ou vous devez fournir les informations d'identification du proxy chaque fois que vous ouvrez un terminal.

Outre le défaut .bashrc d'Ubuntu, de nombreux alias conviviaux (pour ls et grep pour imprimer des résultats colorés), de nombreuses nouvelles définitions pour différentes variables de shell améliorent l'expérience utilisateur.

Mais dans le cas de votre connexion ssh ou connexion à la console virtuelle , vous obtenez essentiellement un shell de connexion interactif. Le fichier d'initialisation du shell est ~/.profile . Par conséquent, à moins que vous n'utilisiez ~/.bashrc , vous perdez tous ces paramètres utiles dans votre .bashrc . C’est la raison pour laquelle ~/.profile source ~/.bashrc

par défaut d'Ubuntu

Dossier à éviter

  • vous ne devez jamais générer ~/.profile form dans ~/.bashrc au même moment où ~/.bashrc provient de ~/.profile . Cela créera une boucle infinie de situation et par conséquent votre invite de terminal sera suspendue à moins que vous n'atteigniez 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.

    
réponse donnée souravc 11.03.2014 - 04:06
la source

Lire d'autres questions sur les étiquettes