Pourquoi la source Bash distante .bash_profile au lieu de .bashrc
Bash Manual dit:
Bash tente de déterminer quand il est exécuté avec son entrée standard connectée à une connexion réseau, comme lorsqu'il est exécuté par le démon Shell distant, généralement rshd, ou le démon Shell sécurisé sshd. Si Bash détermine qu'il est exécuté de cette manière, il lit et exécute les commandes à partir de ~/.bashrc, si ce fichier existe et est lisible.
Cette source Bash ~/.bashrc:
ssh user@Host :
Mais ce Bash sources ~/.bash_profile:
ssh user@Host
Je ne vois pas de différence dans ces deux commandes selon la spécification. Stdin n'est-il pas connecté à une connexion réseau dans les deux cas?
Un shell de connexion lit d'abord /etc/profile et alors ~/.bash_profile.
Un shell sans connexion lit à partir de /etc/bash.bashrc et alors ~/.bashrc.
Pourquoi est-ce important?
En raison de cette ligne dans man ssh:
Si la commande est spécifiée, elle est exécutée sur l'hôte distant au lieu d'un shell de connexion.
En d'autres termes, si la commande ssh n'a que des options (pas une commande), comme:
ssh user@Host
Il va démarrer un shell de connexion, un shell de connexion lit ~/.bash_profile.
Une commande ssh qui a une commande , comme:
ssh user@Host :
Où la commande est : (ou ne rien faire).
Il va pas démarrer un shell de connexion, donc ~/.bashrc est ce qui sera lu.
Stdin à distance
La connexion tty fournie pour/dev/stdin sur l'ordinateur distant peut être un tty réel ou autre chose.
Pour:
$ ssh sorontar@localhost
/etc/profile sourced
$ ls -la /dev/stdin
lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0
$ ls -la /proc/self/fd/0
lrwx------ 1 sorontar sorontar 64 Dec 24 19:34 /proc/self/fd/0 -> /dev/pts/3
$ ls -la /dev/pts/3
crw--w---- 1 sorontar tty 136, 3 Dec 24 19:35 /dev/pts/3
Ce qui se termine par un ATS (pas une connexion réseau) comme le bash démarré le voit.
Pour une connexion ssh avec une commande:
$ ssh sorontar@localhost 'ls -la /dev/stdin'
sorontar@localhost's password:
lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0
La liste des ATS commence de la même manière, mais notez que/etc/profile n'a pas été fourni.
$ ssh sorontar@localhost 'ls -la /proc/self/fd/0'
sorontar@localhost's password:
lr-x------ 1 sorontar sorontar 64 Dec 24 19:39 /proc/self/fd/0 -> pipe:[6579259]
Ce qui indique au Shell que la connexion est un canal (pas une connexion réseau).
Ainsi, dans les deux cas de test, le shell ne peut pas savoir que la connexion provient d'un réseau et ne lit donc pas ~/.bashrc (si nous ne parlons que de la connexion à un réseau). Il lit ~/.bashrc, mais pour une raison différente.
Vous posez des questions sur le "pourquoi" et non sur le "comment", je vais donc essayer de répondre dans cette perspective. Ce qui suit sera une bonne partie de la raison pour laquelle les choses se sont passées dans le passé pour aboutir à la façon dont elles se produisent aujourd'hui.
La raison d'avoir deux fichiers de démarrage différents ("profil" et "rc") est que dans le passé, la façon courante de travailler sur une machine était:
Connectez-vous à partir d'une sorte de terminal réel ou d'un autre poste de travail et obtenez un shell de connexion . Ce Shell invoquera
/etc/profileet~/.profileet configurer l'environnement pour l'utilisateur.Appelez l'environnement dans lequel l'utilisateur souhaite entrer. Cet environnement pourrait être Xorg, mais dans la plupart des cas, il s'agissait d'un multiplexeur tel que l'écran GNU.
L'environnement (par exemple GNU) invoquerait alors des shells supplémentaires (sans connexion) qui héritent de l'environnement du shell de connexion parent.
C'était la manière courante de se connecter à une machine UNIX au moment où csh et bash étaient en cours de développement. Par conséquent il a été jugé inutile de lire ~/.profile encore dans les shells qui héritaient de toute façon l'environnement.
bash puis ajouté ~/.bashrc pour une configuration supplémentaire pour ces shells sans connexion. csh (et tcsh) n'a jamais ajouté aucun type de fichier "rc" pour les shells sans connexion. Notez que csh/tcsh ne sont pas des shells compatibles avec le bourne Shell (qui fait partie de POSIX) alors que bash l'est. Un autre shell compatible avec Bourne, ksh, a ajouté une variable d'environnement (appelée ENV) qui, si elle était définie, serait utilisée comme fichier de commandes d'exécution ("rc") pour les non-connexions ksh.
Donc oui, les nouvelles versions des shells bourne ont ajouté le fichier de configuration supplémentaire pour des alias et d'autres options rapides qui seraient présentes à l'intérieur des shells muxed par GNU (ou similaire) mais non présent dans le Shell que vous obtenez lorsque vous entrez pour la première fois dans la machine.
Avec l'augmentation des gestionnaires d'affichage graphique (GDM), la différenciation entre les fichiers "profil" et les fichiers "rc" est devenue sans signification car le GDM aurait ses propres fichiers d'initialisation (par exemple ~/.xinit et ~/.xsession). Ensuite, les shells indiqués depuis l'intérieur du GDM peuvent être des shells de connexion ou de non-connexion selon les caprices d'un utilisateur, et le cas dans lequel un shell sans connexion aurait toujours un parent qui est un shell de connexion n'est plus vrai.
Supplémentaire
Un de mes tableaux préférés sur la comparaison des fichiers de démarrage Shell montre comment les shells compatibles bourne Shell utilisent les fichiers profile tandis que les autres shells ne le font pas. En effet, dans le passé, le shell initial (celui qui a démarré le multiplexeur) devait être un shell compatible bourne.