LINUX.ORG.RU

ssh внутри скрипта unexpected EOF

 , ,


0

1

Всем привет.

Пишу скрипт, суть которого собрать с машин данные, а потом делать с ними что захочу.

В скрипте есть массив с ip адресами машин, я делаю

systems=( ip1 ip2 ip3 )
for system in "${systems[@]}"
do
	ssh root@$system multipath -ll > mpath$system
	if [[ $? -ne 0 ]]; then
		echo "`date` problem with connect to $system"
		continue
	fi
	ssh root@$system virsh list --all > vl$system
done


И в последней комманде последней машины (т.е. до этого везде всё хорошо) получаю ошибку
>script.sh: line 115: unexpected EOF while looking for matching ``'
с дебагом выглядит так:
+ ssh root@ip1 virsh list --all
+ for system in '"${systems[@]}"'
+ ssh root@ip2 multipath -ll
+ [[ 0 -ne 0 ]]
+ ssh root@ip3 virsh list --all
script.sh: line 115: unexpected EOF while looking for matching ``'

Встречался ли кто-то с подобными проблемами, как и почему это происходит, или, хотя-бы, в какую сторону копать?

Заранее благодарен

PS. Англоязычные интернеты полны такими же ошибками, но там везде используется cat EOF; EOF.

PPS. Так же частая проблема - это синтаксис. Я уже сократил цикл до просто двух ssh команд, даже без вывода в файл. Это наталкивает меня на мысли о том, что проблема в массиве. А так же, когда убрал лишнее - изменились цифры в указании строки. Это третья с конца строка скрипта и последняя. Такое впечатление, что где-то вместо того, что бы увидеть конец массива - он пытается получить еще один элемент, а дальше не воспринимает файл. Просто видит весь файл аж до третьей строки с конца.

UPD: я закомментил весь скрипт дальше, просто первый цикл выполняется. Если раскомментить второй - начинается ошибка. Ща буду в него смотреть

UPD2: похоже, проблема в следующем цикле в конструкции

if echo $line | grep -q -E "\([a-z0-9]{33}\)"; then
 #statements
continue
Странно, запуская руками - всё работает отлично

★★★

Последнее исправление: Crystal_HMR (всего исправлений: 3)

И вообще — не надо в новых программах использовать возможности, оставленные для совместимости, и в частности непарные `` вместо парных $().

Как везде исправите, так и найдете, какую потеряли.

Zmicier ★★★★★
()
Последнее исправление: Zmicier (всего исправлений: 1)
Ответ на: комментарий от Zmicier

Не вижу. В программе ниже нет 115 строк.

а так сильно нужен именно весь скрипт?) Стыдно показывать говнокод, да и думал я, что не нужен он. Учитывая UPD2 - похоже нужен был хотя бы след. цикл.

Crystal_HMR ★★★
() автор топика

вангую проблему, которая решается ключем -n для команды ssh

одна из команд ssh завершается с ошибкой, закрывает /dev/stdin, и весь цикл останаливается.

bl ★★★
()
Ответ на: комментарий от Zmicier

по поводу парных скобок - честно сказать, я знал, что так можно, но не знал, что непарные кавычки - это, так сказать, наследие. Похоже просто слишком много старых статей, в которых я искал ответы.

PS. Вопрос не в кавычках. Я поменял везде, это не помогло.

Crystal_HMR ★★★
() автор топика

Точно все ифы закрыл? А если в конце перенаправление заменить на

> /dev/null 2>&1 & 

Что получится?

Pyzia ★★★★★
()
Последнее исправление: Pyzia (всего исправлений: 1)

в конструкции
if echo $line | grep -q -E "\([a-z0-9]{33}\)"; then

Костыльная конструкция.

if [[ $line =~ \([a-z0-9]{33}\) ]]; then

Zmicier ★★★★★
()
Последнее исправление: Zmicier (всего исправлений: 1)

В массиве айпишников мусора нет?

legolegs ★★★★★
()
Ответ на: комментарий от Zmicier

Как это не в кавычках, когда у вас незакрытая кавычка.

грешен, каюсь... таки да. Была дальше не закрытая кавычка :(

Конструкцию тоже поменял (еще до комментария). Но спасибо! Огромное.

Crystal_HMR ★★★
() автор топика
Последнее исправление: Crystal_HMR (всего исправлений: 1)
Ответ на: комментарий от Zmicier

Костыльная конструкция.
if [[ $line =~ \([a-z0-9]{33}\) ]]; then

На всякий случай — в bash до версии 4 нужны дополнительные \. Так что, что костыль ещё не факт.

vodz ★★★★★
()
Ответ на: комментарий от vodz

Спасибо. Правда самые старые, что я нашел:

GNU bash, version 4.3.30(1)-release (powerpc-ibm-aix5.1.0.0)
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)

:)

Crystal_HMR ★★★
() автор топика
Ответ на: комментарий от Crystal_HMR

Спасибо. Правда самые старые, что я нашел:

Ну так то да, но это демонстрация почему bash-измы плохи. Не только тем, что в других шеллах скорее всего не будет «=~ regex», а даже в том, что это появилось в bash не сразу и даже не сразу в текущем синтаксисе.

Если б не ваши {33} то можно было б просто заюзать стандартные шелл-средства, поддерживаемые чуть ли не с рождения bourne-shell-ов в виде «case» или чуть современных «${var#%pattern}».

vodz ★★★★★
()
Ответ на: комментарий от vodz

в других шеллах

меня на эту тему оправдывает разве что то, что в других шеллах это работать и не должно. Настолько специфичные вещи, что выкладывать их в общий доступ не имеет смысла, а мне - один раз сделать, через 10 лет кто-то это раскопает, скажет «а оно всё еще работает, BUT HOW?», да и хватит

Crystal_HMR ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.