Il était une fois, une invocation ssh à la commande host1
like ssh u@host1 command
lisait .bashrc avant d'exécuter la command
. host2
est administré par les mêmes personnes et lit.bashrc!
Je ne gère pas host1
ou host2
, mais au cours des 6 derniers mois, il semble que ce comportement ait changé.
Il semble maintenant qu'aucun fichier rc ne soit lu lors de la connexion: j'ai édité .profile, .bash_profile, .bashrc, .login
pour ajouter leur nom à une variable lors de la lecture ( export READ=$READ:.profile
)
Les résultats m'ont surpris:
> ssh u@host1 bash3.2> echo $READ :.bash_profile:.profile
Comme je l'attendais.
> ssh u@host1 echo \$READ >
Alors maintenant, je suis bloqué. Des suggestions sur la façon dont cela pourrait se produire? Est-ce un problème de configuration SSHd?
Et juste pour information: host2
exécute une version d'OpenSSH encore plus ancienne que host1
, et les deux exécutent la même version bash. host1
exécute AIX, host2
exécute linux.
Edit : Je ne peux pas changer la ligne de commande ssh
parce que l'objectif ici est de faire fonctionner correctement, pour un couple de non-super-utilisateurs, où git
est installé (pour d'autres raisons) sur un chemin non standard. La relation avec cette question est que, parce que l'emplacement de git-unpack
est spécifié dans .bashrc
, le git clone
de cette télécommande a cessé de fonctionner. Donc, le problème de RC doit être résolu, car j'essaie de configurer cela pour les non-super-utilisateurs, et donc git-clone -u
n'est pas vraiment une réponse satisfaisante.
Dans cette instance particulière, la réponse apparaît (malheureusement) comme une instance de logiciel de buggy (ou un bug très similaire à celui qui est lié).
Si vous contrôlez bash sur cette machine, vous pouvez le réparer en recompilant bash avec #define SSH_SOURCE_BASHRC
; Cependant, ce n'est pas le cas pour moi, alors je suis coincé à la recherche d'autres options.
J'espère que cela aide quelqu'un.