Массив и пробелы

по серьёзному: нужно писать интерпретатор bash на bash

по быдлокодерскому: eval нельзя заюзать?

пробовал с эвалом. не получилось

Взять python и сделать нужное, например, несколькими наборами токенайзеров.

в питоне уже есть рабочие интерпретаторы bash

read -ra array <<< ${string} не подойдёт?

К херам bash.

не работает.

понятно, что так работает.
но как ты for'у передашь строку?

Ну тогда втупую:

$ array=(' 11 1 1 ' "2 2 22" 3\ 3\ 3)
$ echo ${array[0]}
11 1 1
$ echo ${array[2]}
3 3 3
$ echo ${array[1]}
2 2 22

оплата звёздами тут: https://github.com/AnimusPEXUS

#!/bin/bash

a="'1 2 3' \"4 5 6\" 7\ 8\ 9"
b=`bash -c "for i in $a;"' do echo $i ; done'`
# echo "\$b == $b"

for i in "$b"
do
	echo -e "$i\n"
done

понятно, что так можно.
но строка то читается из файла

http://citforum.ru/howto/smart-questions-ru.shtml

о чудо! работает.
благодарю. жаль только что лишний раз bash вызывать.
может ещё набегут эксперты и посоветуют более красивый вариант. пока не буду помечать как решённую.

Там есть shlex и subprocess.

На мой взгляд это тот случай, когда лучше использовать python.

shlex – Lexical analysis of shell-style syntaxes.

Note: Три одинарные кавычки - начало/окончание строки.

import shlex

print(list(shlex.shlex( ''' ' 11 1 1 ' "2 2 22" 3\ 3\ 3 ''', posix=True)))

[' 11 1 1 ', '2 2 22', '3 3 3']

Я вот что думаю, если ТС для своей задачи «сверху» тоже возьмёт нормальный язык программирования, а не Bash, возможно ему даже этот лексер не понадобится, т. к. будет всё сразу по-людски и сабжевый вопрос просто не возникнет.

А можно разъяснить, почему это работает и в чём суть такой расстановки кавычек?

Почему с eval не получилось?

$ var="' 11 1 1 ' \"2 2 22\" 3\ 3\ 3"
$ eval set $var
$ echo "$1"
 11 1 1 
$ echo "$2"
2 2 22
$ echo "$3"
3 3 3
$ for val; do echo "$val"; done
 11 1 1 
2 2 22
3 3 3

чём суть такой расстановки кавычек

в том, что параметры в bash разделяются пробелами.

чтобы это оставался один и тот же параметр, просто не оставляешь пробел между «и'

ну и, в двойных кавычках - $i подставляется, а в одинарных - нет

с eval не получилось?

Плюсую.

Плюсую

var='`rm -fr --no-reserve-root /`'

var='`rm -fr --no-reserve-root /`'

Ой, баюсь, баюсь...

Чего боишься, клоун? Поставь set -x, вместо rm другую команду и посмотри, как отработает предлложенный выше скрипт.

Чего боишься

Вот именно. Подменяешь понятия и смысл вопроса. Что дальше?

Какие, к чёрту, понятия?

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

они распространяют дярявый говнокод

Какой к чорту «код»? И вообще, кто тот «отмороженный», который придумал называть команды bash «кодом»?

Это вообще к чему?

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

Это вообще к чему?

комментарий: zvezdochiot (28.05.19 15:29:52).

Там по ссылке какой-то невнятный тупак.

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

Учитывая, что ТС сам упомянул eval, логично предположить, что он в курсе рисков данного метода.

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

Да, давно уже пора сделать standalone парсер шелловской грамматики в части кавычек и экранирования и использовать его из скриптов как внешнюю утилиту. Но я такого ещё не встречал, а написать пока ленюсь.

Дело вкуса, но тащить из-за этого Питон, мне кажется некрасивым.

Если посмотреть темы ТС, видно, что он любитель странного и не особо разбирается в баше, хотя использует его уже весьма долго.

благодарю!
про set то я и не подумал

Что это было?

Решение проблемы ::)

то есть, LOR - официально - всё?

@next_time не, ЛОР сам себя удалил случайно https://github.com/maxcom/lorsource/issues/873, но феникс возродился в капсе ::)

Блин next_time Массив и пробелы (комментарий)

Решение проблемы ::)

Ни на йоту.
Ты тупо убрал некоторые символы из строки. ТС хотел совсем другого.
Кроме того, ты это сделал простынёй, когда можно было сделать одной строкой.
Применять микроскоп нужно по его прямому назначению.

Ему и дано тупо удалить символы, а если у него там миллионы строк в строгом формате (да надо внести изменения) то однострочники будут тратить драгоценное время. Я предложил, выбирать как быть дело ТС

Ему и дано тупо удалить символы, а если у него там миллионы строк в строгом формате (да надо внести изменения) то однострочники будут тратить драгоценное время. Я предложил, выбирать как быть дело ТС

TC просил разбить строку на элементы массива. В его примере - три элемента массива.

И он ничего не говорил про миллионы строк и какую-то драгоценность времени. Не додумывай требований.

Не додумывай требований.

Ну ладно ::(

Встроенная парсилка кавычек есть в xargs

$ xargs printf '[%s]\0' <<EOF
' 11 1 1 ' "2 2 22" 3\ 3\ 3
EOF
[ 11 1 1 ][2 2 22][3 3 3]

выкинь поскорее это опасное убожество с eval и посмотри на этот ответ на стековерфло: https://stackoverflow.com/questions/26067249/reading-quoted-escaped-arguments-correctly-from-a-string/31485948#31485948

выкинь поскорее это опасное убожество с eval

Тю, а сам то кавычки у EOF забыл поставить.

$ xargs printf '[%s]\0' <<EOF
' 11 1 1 ' "2 2 22" 3\ 3\ 3 $(echo excute rm)
EOF

если предварительно в строке заэкранировать опасные символы, eval не будет опасным.

Да, косяк. Но у ТС вообще из файла данные, а here doc я чисто для примера притащил.

Как-то глупо очищать данные перед подачей в сложный и опасный парсер, когда есть простой и безопасный парсер. Чем проще система, тем она надёжнее и легче поддерживается.

Ещё проще бы было хранить данные с разделителем, через табуляцию например.

чем проще система, тем она надёжнее и легче поддерживается.

И тем больше раздражает своей тупостью по возможностям. Ибо сегодня простое будет достаточно, а завтра и $VAR захочется, а то и ${VAR[idx]}, но чтобы $(var) не делало, но была разница у $VAR и «$VAR» и так далее.

А не надо такого хотеть! А то так можно и до sendmail.cf дойти или чего похуже.