Как каждую строку вывода записать в переменную?

https://www.gnu.org/software/bash/manual/html_node/Command-Substitution.html

https://www.gnu.org/software/bash/manual/html_node/Looping-Constructs.html#index-for

/thread

xargs -I{}

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

$somevar = aptly mirror list -raw # и дальше опперировать массивом?

xargs

RTFM

$ printf "abc\n123\nqwerty" | xargs -IXXX echo blabla1 XXX blabla2 XXX
blabla1 abc blabla2 abc
blabla1 123 blabla2 123
blabla1 qwerty blabla2 qwerty

for s in $(echo foo bar baz); do
	echo $s
done

«You almost never need xargs.»

Спасибо. Вы очень помогли мне сделать крутой скрипт!

Потому что для нубов баш это вот это вот всё, что в терминале вертится.

Учти, что $(cmd) разделяет вывод команды cmd на отдельные части согласно содержимому $IFS, которая традиционно содержит пробел, таб и line feed (\n).

крутой скрипт!

Имена файлов с пробелами правильно отрабатывает?

Дело не в том что, баш вот это всё, а в том что зачем усложнять и выдумывать что-то ещё?

к тому же что-то ещё иногда надо дополнительно устанавливать.

Соответственно, где-то может не быть, и оно требует дополнительных ресурсов.

Имена файлов с пробелами правильно отрабатывает?

какими пробелами? =)

Ты ещё про имена файлов с переводами строк спроси.

Как в меме - боже, они же ещё дети.

Баш существует как усложнение и выдумывание чего-то всё.

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

Проблема баша в том, что его приходится изучать и в нём куча грязных хаков, которые неприменимы к нормальным ЯП. Для демонстрации: bashpitfalls. Поэтому лучше использовать либо нормальный современный ЯП, либо более адекватный шелл (я лично рекомендую rc), если принципиально хочется запускать команды.

оно требует дополнительных ресурсов

Миром правит докер. Война за ресурсы проиграна.

В фише можно:

 ~ cat tfile 
aaa
bbb
ccc
 ~ set v (cat tfile)
 ~ echo $v[1]
aaa
 ~ echo $v[2]
bbb
 ~ for line in $v ; echo 'LINE '$line; end
LINE aaa
LINE bbb
LINE ccc
 ~ echo $v[-1..1]
ccc bbb aaa
 ~ count $v
3

Но это именно строки. Если в строках между токенами пробелы, то нужно ещё дополнительно самому разбивать:

 ~ string split ' ' 'xxx yyy zzz'
xxx
yyy
zzz

Миром правит докер. Война за ресурсы проиграна.

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

Может лучше ридом тогда? Типа:

aptly mirror list -raw |
while IFS= read; do
    aptly snapshot create "$REPLY" \ 
    from mirror "$REPLY"
done

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

Мне тут в книжке объяснили, что это язык управления, просто клей для готовых инструментов, вот и всё.

А уродливый вид он имеет по одной простой причине: развивается эволюционно, то есть просто реагирует на ситуацию.

никак не хочет быть языком программирования.

Мне тут в книжке объяснили, что это язык управления, просто клей для готовых инструментов, вот и всё.

Согласен. Несмотря на то, что технически шелл это интерпретатор, философски он таковым не является. Выполняемая функция - именно что командная оболочка, имеющая удобный запуск програм и для них обработку ввода/вывода. Всё остальное, что образовалось сверху, можно отнести к свистелкам.

А уродливый вид он имеет по одной простой причине: развивается эволюционно, то есть просто реагирует на ситуацию.

Ну так эволюции тут не место. В архитектуре ПО инженерам нужна не какая-то случайная эволюция, а либо итеративный процесс, либо переписывание велосипедов.

Относительно sh, bash ещё какой язык программирования. То есть, буквально, bash - это прямое отступление от принципа что шелл это язык управления.

Несмотря на то, что технически шелл это интерпретатор, философски он таковым не является.

Хотелось бы подробностей, но что-то мне подсказывает, что под термином «интерпретатор» ты имеешь в виду нечто, что я не смогу понять.

Выполняемая функция - именно что командная оболочка, имеющая удобный запуск програм и для них обработку ввода/вывода. Всё остальное, что образовалось сверху, можно отнести к свистелкам.

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

Ну так эволюции тут не место. В архитектуре ПО инженерам нужна не какая-то случайная эволюция, а либо итеративный процесс, либо переписывание велосипедов.

Ну, ведь никто не накладывает ограничений, то есть заинтересованные люди могут всем этим заниматься, но это будет точно не баш.

Это как и с операционными системами и, наверное, с прочими технологиями, где есть реальные живые востребованные вещи и они всегда имеют этимологию, исторический процесс, зависимости, которые никак нельзя отменить, и которые является причиной уродства, стагнации, ригидности и т.д., однако пароход идёт…

Отсюда наиболее общий вопрос. А так ли уж много действительно хороших полезных вещей создано архитекторами и дизайнерами с нуля, то есть путём отмены старого и полного переосмысления, или всё таки это фантазии, идеализм, а реальность иная.

буквально, bash - это прямое отступление от принципа что шелл это язык управления

Можно какие-нибудь описательные примеры того, что делает баш реально языком программирования в отличие от?

Я не программист, поэтому вынужден верить на слово авторитетам, и они говорят, что нет, баш не пригоден для программирования, только для сценариев, то есть управления.

На личном опыте. Я честно пытался учить паскаль и си, и никуда не продвинулся, я просто не могу найти реального применения для этих вещей, и мне вообще непонятно о чём всё это (математика какая-то…), но когда таки взялся за баш, то через некоторое время обнаружил, что у меня уже вся система обмазана скриптами и конца и края не видно открывающимся возможностям. И теперь совершенно очевидно, что чем лучше линуксоид знает баш, тем удобнее ему живётся, но программистом он от этого не становится, нет.

https://www.gnu.org/software/bash/manual/html_node/Major-Differences-From-The-Bourne-Shell.html

но когда таки взялся за баш,

А вы преходите с баша на posix shell. Тогда, возможно, разница станет для вас более отчётливой.

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

В качестве командной оболочки лучше подходит zsh. В качетве языка сценариев — бабашка вне конкуренции. Но у баша есть суперсила — он везде установлен и его все знают.

вы преходите с баша на posix shell

Знаешь, вот именно распыление и отбросило когда-то меня от хоть каких-то результатов. То мне тулили, что надо учить shell для совместимости, то я, будучи бздуном, пытался разобраться в cshell, и в результате тормозил.

На самом деле не было нормальных книг тогда. Теперь приличные есть и меня наконец убедили, что bash это навсегда, он есть везде и будет всегда, точка.

Так что твоему совету не последую ☺️

Чем лучше? От интерактивного шелла требуется ведение истории команд, хоть какой-то поиск по ней, и нормальное редактирование командной строки перед отправкой (всмысле что можно стрелками двигать курсор влево и вправо и стирать/добавлять символы в середину). Баш это всё умеет, sh в линуксе - обычно нет. Впрочем, в фрибсд это всё умеет и обычный sh и традиционный для этой системы csh, так что смысла в баше там нет. В других шеллах смысла тем более нет, они мало того что ничего полезного не добавят, так ещё и нуждаются в отдельной установке.

Чем лучше?

Примерно всем.

От интерактивного шелла требуется

Да, в смысле без этого совсем грустно, но нет, в смысле аппетит приходит во время еды и хочется всякого.

ничего полезного не добавят

Т.е. всё, что баш умеет, это абсолютно необходимо. А что не умеет — бесполезная хипстерская вытребонька? Эдакий парадокс Блаба для оболочек получается.

Примерно всем.

По ссылке много цветных скриншотов и обещание «тем формления». Полезное там что-нибудь есть?

Т.е. всё, что баш умеет, это абсолютно необходимо

Нет, в баше тоже огромное количество лишнего хлама, который туда добавили пытаясь изобразить из него язык программирования. Необходимо (в плане интерактивности) только нормальное управление вводом командной строки. За образец «есть всё что нужно, и нет ненужного мусора» можно примерно считать /bin/sh из новых (10 и выше) версий фрибсд, в старых он был таким же недоинтерактивным как и линуксовый.

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

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

В огороде бузина, в Киеве дядька. Если вам недостаточно велосипеда, купите солнечные очки.

# такое работает только в баше
# и очень похоже на конструкции из обычных языков программирования
for ((i=0; i<3; i++)) {  echo $i ; }
[[ 2 = 2 && (4 == 3 || 5 == 5) ]] && echo 'YES'
S='abcdef' ; echo ${S:1:3}  # подстрока

В sh этого безобразия нет и там предлагается использовать сторонние утилиты, к примеру expr 5 - 3. Хотя и сказать что sh какой-то особенно ортогональный, и есть только способ сделать это, тоже нельзя.

Захотите найти полезное — найдёте. А не захотите — не найдёте. Всё зависит только от вас.

Уже не везде. В тонких докерах его почти никогда нет, только sh.

Необходимо (в плане интерактивности) только нормальное управление вводом командной строки

Сурово.

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

А, так месье виндузятник. Так бы сразу и сказали.

Ну, в докерах иногда и /bin/sh тоже нету. Это особая статья.

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

Сам ты виндузятник.

И такое бывает, да. Но шелл я чаще пишу под докер, чем куда-либо ещё, не такая уж особая статья.

Если вам регулярно нужно заходить в командную оболочку в докере — вы делаете что-то очень-очень неправильное. Это либо для отладки и прочего экстрима, либо чуть подхачить среду перед запуском основной команды. В обоих случаях оболочка должна быть максимально лёгкой и простой. Это вообще отдельная ситуация от нормального использования.

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

Либо так, либо идти путём боли и страданий. Докер подразумевает определённую модель использования.

Эта ветка идет как продолжение вопроса, чем zsh лучше. Так всё таки чем?

for ((i=0; i<3; i++)) { echo $i ; }

В sh нету for i in $(seq 1..3); ...?

[[ 2 = 2 && (4 == 3 || 5 == 5) ]]

Это всё есть в [, просто выглядит не так красиво.

… && echo ‘YES’

Это сокращение для if и, КМК, наоборот не похоже на традиционное программирование. Жить без этого можно и в bash, но штуки классные, да.

S=‘abcdef’ ; echo ${S:1:3}

До этого руки ещё не дошли, всё cut и sed мучаю. Скоро разберусь 😁

предлагается использовать сторонние утилиты, к примеру expr 5 - 3

Ну да, (()) удобнее, выглядит красивее, но принципиальной разницы пока не вижу.

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

А как оно, кстати, программировать с одномерным массивом и без плавающих точек, нормально? Больше интересует первое, а то что-то ленюсь использовать эту тему, а для арифметики, ясно, есть bc (опять же, как в sh).

Массивы, да. Без работы с массивами в sh тяжко.

А перечисленное выше это просто сахар. Согласен.

На баше сложно именно программировать

А сшивать процессы пайпами конечно же никакой питон и рядом не стоял

То есть никакого перехода от чисто шелла к прям языку программирования нет. Дык и я то же самое цитировал — язык управления 😁

чем zsh лучше

Тоже интересно, чего на него так залипает народ.

Без работы с массивами в sh тяжко.

Мне просто интересно. Могу не понять, лучше попроще пример. А где тебе прямо пипец как пригождаются массивы в баше? И вообще как часто?

Строго говоря, даже sh вполне себе язык программирования, даже тьюринг-полный, то есть на нём можно сделать любое вычисление. Любой шелл это специализированный язык программирования. А язык управления это скорее такой народный термин (англовики предлагает термин поинтереснее: командный язык). Собственно переход от sh к bash делает его совсем немного менее специализированным, и критика обычно сыпется не на этот факт сам в себе, а на то, что bash как язык классического программирования довольно плохой. Сталкиваешься с десятком крупных трудночитаемых скриптов, и чешется отговаривать всех пользоваться надмножеством баша, достаточно его sh подмножества.

Я не то что б часто что-то крупное пишу на bash, но скажу в целом по опыту программирования на шеллах.

«Собрать коллекцию однотипных штук и потом обработать» – это типовое действие при решении задач на любых ЯП, а на ЯП с такой бедной палитрой типов данных как у шелла, оно становится еще востребованнее.

И в sh единственный массив, который тебе дают на руки - это "$@". И порой через него и приходится выкручиваться, с вызовом функций, shift и так далее. Но вызовы функций имеют собственные ограничения и не всегда ложатся в нужный алгоритм.

Вообще большая часть программирования на sh и состоит из этого: выкручиваться. Когда у тебя на каждую фичу по полдюжины антич, и тебе мало придумать алгоритм – тебе еще надо придумать, как его закодировать на этом эзотерическом языке, обойдя все грамотно расставленные капканы.

Ну своего рода это тоже удовольствие – типа как в Римку поиграть на «Проигрывать весело» и получать кайф от того, что «я из такой жопы вышел победителем в очередной раз».

Тут еще что важно, на мой взгляд. Если человек ишет про преимущества bash и в числе основного упоминает сахар [[ ]], а работу с массивами и дополнительные фичи по parameter expansion не упоминает – значит он ничего существенного на sh не писал.

Потому что всратый синтаксис для условных выражений – это конечно неприятно, но терпимо. Мы со знанием синтаксиса не рождаемся, остальные синтаксисы мы точно так же учили. А гораздо хуже, когда операционная модель шелла никак не налазит традиционные ЯП и привычные паттерны проектирования, и приходится изобретать язык внутри языка из костылей и подпорок. При этом подпорки не удаётся завернуть в абстракции, а они так и лежат кишками наружу, в результате чего программирование становится похоже на то, что ты в уме компилируешь алгоритм и пишешь его в извращенных машкодах этого промежуточного языка. Вот bash даёт больше инструментов, чтобы код был чуть более высокоуровневым.