Rsync кажется несовместимым с .bashrc (вызывает «ваша оболочка чиста?»)

16

Оказывается, rsync не может работать с удаленным сервером, на котором есть файл .bashrc?

На локальном клиенте я получил при запуске 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]

Как предложено здесь, удаление .bashrc на сервере решило проблему. Как решить это, не удаляя файл .bashrc (временно)?

Computist
источник
1
Проверьте, включен ли ssh для этой учетной записи.
Lamy
Приведенные ниже ответы, вероятно, неверны. Я недавно начал получать эту ошибку после обычного обновления Ubuntu, хотя в моих файлах .bashrc ничего не изменилось.
13:30
Нет - если удаление файла .bashrc исправляет его (как указано в этом вопросе), то проблема выводится из .bashrc. Обновление, безусловно, может привести к фактической несовместимости протокола, что является совершенно другой проблемой.
Рэндалл

Ответы:

21

Вы можете столкнуться с проблемами, если .bashrcна удаленном сервере что-то выводит на терминал. Rsync может не ожидать этого и может иметь проблемы в результате.

Вы можете исправить это, удалив любые команды в этом .bashrcвыводимом тексте или отправив любой вывод в / dev / null.

Грег Хьюгилл
источник
3
Так как же направить любой вывод в / dev / null, если я могу изменять только файлы на клиенте?
Компьютерщик
1
Я полагаю, вы могли бы как ваш системный администратор для помощи. Вы также можете изменить файлы на сервере другим способом, например, FTP или scp.
Грег Хьюгилл
Да, мой файл .bashrc содержал эхо "*** Starting ROOT Shell ***" и echo "(Пожалуйста, используйте sudo вместо корневой оболочки, когда это возможно!)". Устранение этих эхо решило проблему.
Кентграв
1
Со страницы руководства rsync: "Несоответствие версии протокола - чиста ли ваша оболочка?" Это сообщение обычно вызывается вашими скриптами запуска или удаленной оболочкой, производящими нежелательный мусор в потоке, который rsync использует для своего транспорта. Способ диагностики этой проблемы состоит в том, чтобы запустить удаленную оболочку следующим образом: ssh remotehost / bin / true> out.dat, а затем посмотрите на файл out.dat. Если все работает правильно, то out.dat должен быть файлом нулевой длины.
Кентграв
8

.Bashrc на самом деле не является правильным местом для генерации вывода, так как это вызывает проблемы такого рода. Однако многим это сходит с рук, пока они не попытаются запустить rsync :-)

Любой желаемый вывод (и связанные логика и команды) должны быть перемещены в ваш файл .bash_profile (см., Например, вопрос о сбое сервера ".profile vs. .bash_profile vs. .bashrc" для дальнейшего обсуждения различий между файлами).

Таким образом, вам не нужно жертвовать получением выходных данных при входе в систему, а также не делать временных изменений в вашем .bashrc, когда вы хотите использовать rsync.

Randall
источник
6

У меня всегда были файлы .bashrc в моих учетных записях пользователей, и у меня никогда не было этой проблемы, пока я сегодня не попытался что-то rsync на свой сервер, используя учетную запись root. Ваш пост помог мне найти решение:

Мои файлы $ user / .bashrc всегда начинаются со следующего раздела, чтобы избежать подобных проблем. Я скопировал его в .bashrc root, и rsync'ing теперь работает как шарм!

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

HTH, карстен

Карстен
источник
Обычно это не работает rsync, потому что по какой-либо причине классифицируется как «интерактивная оболочка». Но в любом случае это хорошая строка для добавления, потому что в противном случае она может испортить неинтерактивные оболочки, если они есть.
Михаэль Шуберт,
Я думаю, что это лучшее решение вопроса. Ответ "принять" удаление любых команд в .bashrc, выводящих текст "нецелесообразен.
Циньси
4

По сложным причинам rsync / scp / sftp запускает .bashrc при подключении к другому хосту. У вас должна быть любая из этих команд в верхней части вашего .bashrc :

или

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

или

[ -z "$PS1" ] && return

Любая из вышеперечисленных команд разрешит выполнение только остальных команд .bashrc для интерактивных сеансов . Насколько я знаю, они вам не нужны ни для какого другого типа сессии (и действительно, я видел bashrc по умолчанию из Arch и Debian, использующий эту технику в их bashrc).

Однако, если вы хотите быть более параноидальными в том, что ваши команды bashrc должны выполняться даже для неинтерактивных сеансов, вы должны, по крайней мере, обернуть команды вашего bashrc, которые производят вывод, подобный этому ( ссылка ), чтобы они выполнялись только в интерактивных сеансах:

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

Обратите внимание, что другие предлагают перенести команды, выводящие текст, в ваш bash_profile, но у меня есть сомнения по поводу того, всегда ли это хорошо (по причинам, объясненным здесь )

ndemou
источник