Rsync semble incompatible avec .bashrc (provoque "est votre shell propre?")

16

Il s'avère que rsync ne peut pas fonctionner avec un serveur distant qui a un fichier .bashrc?

Chez le client local, j'ai obtenu lors de l'exécution de rsync:

protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(180) [sender=3.0.7]

Comme suggéré ici, la suppression du .bashrc sur le serveur a résolu le problème. Comment le résoudre sans supprimer (temporairement) le fichier .bashrc?

bash rsync

— Informaticien
source

1

Vérifiez si ssh est activé pour ce compte.

— Lamy

Les réponses ci-dessous sont probablement incorrectes. J'ai récemment commencé à obtenir cette erreur après une mise à niveau de routine d'Ubuntu, même si rien n'a changé dans mes fichiers .bashrc.

— Cerin

Non - si la suppression du fichier .bashrc le corrige (comme cela a été indiqué dans cette question), le problème est généré par le .bashrc. Une mise à niveau pourrait certainement introduire une véritable incompatibilité de protocole, ce qui est un problème entièrement différent.

— Randall

21

Vous pouvez rencontrer des problèmes si le .bashrcsur le serveur distant sort quelque chose vers le terminal. Rsync ne peut pas s'attendre à cela et peut avoir des problèmes en conséquence.

Vous pouvez résoudre ce problème en supprimant toutes les commandes du .bashrctexte de sortie ou en redirigeant n'importe quelle sortie vers / dev / null.

— Greg Hewgill
source

3

Alors, comment diriger n'importe quelle sortie vers / dev / null si je ne peux modifier que des fichiers sur le client?

— Computist

1

Je suppose que vous pourriez en tant qu'administrateur système pour vous aider. Vous pouvez également être en mesure de modifier des fichiers sur le serveur d'une autre manière, comme FTP ou scp.

— Greg Hewgill

Oui, mon fichier .bashrc contenait un écho "*** Démarrage du ROOT Shell ***" et un écho "(veuillez utiliser sudo au lieu d'un shell racine dans la mesure du possible!)". La suppression de ces échos a résolu le problème.

— Kentgrav

1

Depuis la page de manuel de rsync: "Non-concordance de version de protocole - votre shell est-il propre?" Ce message est généralement provoqué par vos scripts de démarrage ou votre installation de shell distant produisant des déchets indésirables sur le flux que rsync utilise pour son transport. La façon de diagnostiquer ce problème est d'exécuter votre shell distant comme ceci: ssh remotehost / bin / true> out.dat puis regardez le fichier out.dat. Si tout fonctionne correctement, out.dat doit être un fichier de longueur nulle.

— Kentgrav

8

Le .bashrc n'est vraiment pas le bon endroit pour générer une sortie, car il provoque ce genre de problème. Beaucoup de gens s'en tirent, cependant, jusqu'à ce qu'ils essaient de lancer rsync :-)

Toute sortie souhaitée (et la logique et les commandes associées) doivent être déplacées vers votre .bash_profile (voir, par exemple, la question de défaillance du serveur ".profile vs .bash_profile vs .bashrc" pour une discussion plus approfondie sur les différences entre les fichiers).

De cette façon, vous n'aurez pas à sacrifier l'obtention de la sortie lorsque vous vous connectez, ni à effectuer des modifications temporaires sur votre .bashrc lorsque vous souhaitez utiliser rsync.

— Randall
source

6

J'ai toujours eu des fichiers .bashrc sur mes comptes d'utilisateurs et je n'ai jamais eu ce problème jusqu'à ce que j'essaie aujourd'hui de resynchroniser quelque chose sur mon serveur en utilisant le compte root. Votre message m'a aidé à trouver la solution:

mes fichiers $ user / .bashrc commencent toujours par la section suivante pour éviter ce genre de problème. Je l'ai répliqué sur .bashrc et rsync'ing de root fonctionne maintenant comme un charme!

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

HTH, karsten

— karsten
source

Cela ne fonctionne généralement pas rsync, car il est pour une raison quelconque classé comme "shell interactif". Mais c'est une bonne ligne à ajouter de toute façon, car cela pourrait gâcher des shells non interactifs sinon s'il y a une sortie.

— Michael Schubert

Je pense que c'est la meilleure solution à la question. La réponse d'acceptation "supprimer toutes les commandes dans le .bashrc qui produisent du texte" n'est pas pratique.

— Qinsi

4

Pour des raisons complexes, rsync / scp / sftp exécute .bashrc lors de la connexion à un autre hôte. Vous devez avoir l'une de ces commandes en haut de votre .bashrc :

Soit

[[ $- != *i* ]] && return

ou

[ -z "$PS1" ] && return

N'importe laquelle des commandes ci-dessus autorisera uniquement l'exécution du reste des commandes .bashrc pour les sessions interactives . Pour autant que je sache, vous n'en avez pas besoin pour tout autre type de session (et en effet j'ai vu bashrc par défaut d'Arch et Debian utilisant cette technique dans leur bashrc).

Si toutefois vous voulez être paranoïaque supplémentaire à propos de l'exécution de vos commandes bashrc même pour des sessions non interactives, vous devez au moins encapsuler les commandes de votre bashrc qui produisent une sortie comme celle-ci ( référence ) afin qu'elles ne s'exécutent que dans des sessions interactives:

if shopt -q login_shell; then
    # this is an interactive session, we _can_ display output
    ...code that produces output goes here...
fi

Notez que d'autres suggèrent de déplacer des commandes qui produisent du texte dans votre bash_profile mais j'ai des doutes quant à savoir si c'est toujours bon (pour les raisons expliquées ici )

— ndemou
source