Je viens de passer beaucoup de temps à lire sur la connexion et les shells interactifs et pourquoi on devrait ou ne devrait pas définir lenvironnement variables, fonctions shell, etc. dans les différents fichiers profile et bashrc. Dans ce message , il a été mentionné que des éléments spécifiques à bash comme les options dinvite devraient être définis dans ~ / .bashrc. Cela ma amené à minterroger sur la variable PS1. Dans tous les exemples que jai vus à ce sujet, ils ont quelque chose comme export PS1="". Devrait-il vraiment être exporté vers lenvironnement car il na de sens que pour bash? Juste avoir PS1="" dans mon ~ / .bashrc produit leffet prévu pour moi, mais je me demande sil me manque quelque chose.
Réponse
Cest « correct: PS1 na de sens que dans les instances interactives de bash, il doit donc être défini dans ~/.bashrc et ne doit pas être exporté. PS1 est également significatif dans dautres shells, mais il a une signification différente, car les expansions dinvite diffèrent entre les shells. En fait, même entre les instances de bash, PS1 peut avoir des significations différentes, puisque la signification dépend des options du shell (au moins promptvars).
Lexportation de PS1 vers lenvironnement depuis .profile est un retour aux années 1970, quand il ny avait quun seul shell qui utilisé (le shell Bourne) et il n’avait pas de fichier de configuration. Il fonctionne toujours de nos jours si vous utilisez toujours le même shell et ne le configurez jamais différemment. Mais tous les shells modernes qui ne sont pas conçus uniquement pour les scripts (csh, ksh , bash, zsh,…) lire un fichier de configuration au démarrage interactif (.cshrc, .kshrc, .bashrc, .zshrc,…), donc la méthode des années 1970 nest plus nécessaire. La définition de PS1 et dautres paramètres spécifiques au shell dans un fichier spécifique au shell, sans lexporter vers lenvironnement, évite de casser des choses lorsque vous utilisez une configuration de shell différente ou un shell différent ou un terminal différent qui nest pas capable de montrer votre fantaisie habituelle. La configuration de PS1 dans un fichier spécifique au shell fonctionne tout le temps, alors que la configuration dans .profile et lexporter ne fonctionne que dans des cas «simples», il ny a donc aucune raison de ne pas le faire correctement, mais il y a plein de mauvais tutoriels sur le web et même de mauvaises configurations par défaut dans les distributions. C « est la vie .
Commentaires
- Comment lexportation de
PS1from.profilefonctionne pour les shells bash sans connexion, car ils ne ' t le source? Êtes-vous en train de dire que cela fonctionnerait parce que le non- Le shell de connexion serait dérivé dun shell de connexion et hériterait donc dePS1via lenvironnement? - @MikeSweeney oui, que ' s pourquoi ' est exporté .
- Une des fausses idées dexport de PS1 est de voir
if [ -n "$PS1" ] ; then proceed assuming an INTERACTIVE shell ; fi– qui apparaît généralement dans les fichiers .bashrc des personnes ' pour charger uniquement des éléments tels que la complétion de commande sil sagit dun utilisateur . Donc, voyant que cela fonctionne là-bas, la même logique se retrouve dans les scripts shell, doù " besoin de " pour lexporter. À LA PLACE, nous devrions vérifier utilisateurs teractifs / terminaux avectty -soutest -t 0. - @DouglasDD Indeed. Le test
PS1est dans Debian ' s/etc/profiledepuis des âges, par exemple. Je ne ' ne sais pas doù vient cette mauvaise pratique. Je soupçonne que cela vient dun cas dutilisation particulier (peut-être la détection de connexions rlogin ou ssh?) Où cela a fonctionné. Malheureusement, cela échoue dans de nombreux autres cas, doù les nombreuses questions sur ce sujet ici et ailleurs. - @Gilles ne devrions-nous pas exporter
CLICOLORetLS_COLORSnon plus? @DouglasDD cela signifie-t-il queif [[-z $p1]];then return filenregistrement de mon.bashrcest défectueux?