Как и куда bash убирает элемент массива?

Question

[gohellp]

Решил сделать скрипт, который будет смотреть вывод бота по завершению оного и искать там "reboot", дабы перезапустить его и начать всё заново. Пока не придумал, как сам скрипт буду перезапускать из него же, но не об этом сейчас(хотя, если предложите, как это реализовать, то буду только благодарен). Пока что, тестирую на данном js скрипте:

console.log("test");
console.log("test1");

Сам bash скрипт:

read -p "Enter the programm's path with .js: " path
    cd $path
    echo "node $path/main.js"
    nodeLogs="$(node $path/main.js)"
        echo $nodeLogs
        IFS="\n" read -a nodeLogsArr <<< "$nodeLogs"
            echo "${nodeLogsArr[1]}"
            for element in "${nodeLogsArr[@]}"; do
                echo "$element"
            done
            for logs in ${nodeLogsArr[@]}; do
                if (($logs="reboot")); then
                    echo "U couldn't see it!!!"
                    #git pull
                else
                    echo "$logs"
                fi
            done

Получается так, что скрипт после перевода многострочной строки в элементы массива, куда-то девает второй элемент "test1". Изучал разбиение с помощью IFS по этому гайду. Сделал, вроде, как надо, но оно не хочет работать...

Вывод скрипта:

$ ./test
Enter the programm's path with .js: .
node ./main.js
test test1

test
test

Может, я пытаюсь неправильно разбить строку?

Заранее благодарен за ответ

Answer 1

[xotkot]

в простом случае:

$ x='test1 test2'
$ y=($x)
$ echo ${y[0]} И ${y[1]}
test1 И test2

если же, например, у нас разделитель перевод строки то:

$ x='test 1
test 2'
$ q="$IFS";IFS=$'\n';y=($x);IFS="$q"
$ echo ${y[0]} И ${y[1]}
test 1 И test 2

Comments

[gohellp]

Благодарен.
Такой вопрос, вам, случаем, не известно, что при моём способе происходило внутри скрипта? Насколько я понял, IFS в bash работает, как аналог .split("") в js, только надо конкретно указывать, куда записывать значение. Но, из работы скрипта следует, что оно не совсем так.

[xotkot]

gohellp,
во первых, тебя запутал вывод переменной nodeLogs:

nodeLogs="$(node $path/main.js)"
        echo $nodeLogs

если ты наверняка не уверен в выводе то лучше всегда его закавычивать:

nodeLogs='test
test1'
echo $nodeLogs

выведет
test test1
а если вот так:

nodeLogs='test
test1'
echo "$nodeLogs"

то выведет уже как нужно:

test
test1

где можно видеть что переменная занимает несколько строк.

во вторых,

IFS="\n" read -a nodeLogsArr <<< "$nodeLogs"
            echo "${nodeLogsArr[1]}"

выведет пустоту, так как в массив попадёт только первая строка test
для наглядности

IFS="\n" read -a nodeLogsArr <<< "$nodeLogs"
            echo "${nodeLogsArr[0]}"
            echo "${nodeLogsArr[1]}"

выведет только тест:
test

по ссылке на гайд, что вы дали выше, разбирается обычная строка без переноса, я сильно не разбирался в этом, но похоже в данном случае IFS и read в сочетании с <<< не обрабатывает много строчные переменные, отсюда и выходит что массив будет состоять только из первого элемента ${nodeLogsArr[0]} (значение первой строки) и равный test.

п.с.
по поводу read и многострок есть описание ниже в том же гайде

2: Даже если бы вы использовали это решение с односимвольным разделителем (например, запятой отдельно, то есть без пробела или другого багажа), если значение $string переменной, как оказалось, содержит какие-либо LF(перевод строки), то read будет останавливать обработку, как только он встретит первый LF. Встроенный read обрабатывает только одну строку на вызов. Это верно, даже если вы передаете или перенаправляете ввод только в read оператор, как мы делаем в этом примере с механизмом здесь-строки , и, следовательно, необработанный ввод гарантированно будет потерян. Код, обеспечивающий работу read встроенного модуля, не знает о потоке данных в его структуре команд.

Вы можете утверждать, что это вряд ли вызовет проблему, но, тем не менее, это скрытая опасность, которую следует избегать, если это возможно. Это связано с тем, что read встроенный модуль фактически выполняет два уровня разбиения ввода: сначала на строки, а затем на поля. Поскольку OP требует только одного уровня разбиения, такое использование read встроенной функции не подходит, и мы должны избегать этого.

[gohellp]

Ещё раз, благодарю