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

Окстись!! У аптли есть нормальное апи, чтобы не писать башелпашу!..

Массивы можно эмулировать хэш-табицами. Даже в sh само по себе пространство имён это большая хэш-таблица.

&& echo ‘YES’ это кстати есть и в sh.

seq это сторонняя программа.

Это всё есть в [

всё cut и sed мучаю

разницы пока не вижу

Ну то есть, ты не используешь по большому счёту именно баш :)

лучше массивы не юзать в скриптах

В bash они сложные. В fish ещё более-менее, но тоже бывают wtf, к примеру конкатенация это декартово произведение массивов.

Ну то есть, ты не используешь по большому счёту именно баш :)

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

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

сахар [[ ]]

Я думал сахар это чисто про оформление. Ведь эта штука сильно отличается от test и [, просто умеет то же самое в том числе. Она не совершает подстановок (не надо экранировать). Она как и (()) ещё и переменные узнает по именам. А вот то, что туда никто не заглядывает в поисках метасимволов, что делает код приятным на вид, это прямо кайф, ну и родная сестра, (()), забирает на себя всё что связано с числами — тоже красиво сделано. Ну и, конечно, самое главное — возможность сравнивать с шаблонами wildcard & regex. Разве это сахар?

Вот bash даёт больше инструментов, чтобы код был чуть более высокоуровневым.

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

Прошу пардону, я все очки спора и убеждения в теме выбора языка обучения потратил. Так что давайте вы сами как-нибудь документацию прочитаете или в гуге zsh vs bash забъёте, например.

Если вы пришли из большого программирования, то вы мыслите в терминах односвязных списков, деревьев, массивов, словарей и прочих алгебраических структур данных. И когда их нет, вам прямо физически больно, будто ногу отрезали и кадриль танцевать заставляют.

Походу, что такое высокоуровневый код я тоже совсем не понимаю.

Высокий уровень означает, что я должен мыслить задачу в терминах предметной области. А если я вынужден тратить бесценный сок своего мозга на необходимость помнить, чем test, [, [[, ( и (( различны меж собою, то это уже само по себе вызывает желание не касаться этой дряни любой ценой.

Я бы так делал, когда в этом есть необходимость: 1 2

Я бы попробовал сделать через shift если выходной формат позволит. А если не позволит - через временные файлы в /tmp.

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

➜  a tree
.
├── list.bb
├── list.sh
├── Лев Толстой: "Война и мир".txt
└── Фёдор Достоевский: "Бесы".txt

1 directory, 4 files
➜  a ./list.sh
Мои книги:
Лев
Толстой:
"Война
и
мир".txt
Фёдор
Достоевский:
"Бесы".txt

➜  a ./list.bb
Мои книги:
Фёдор Достоевский: "Бесы".txt
Лев Толстой: "Война и мир".txt

Весь пласт специфического шелл-знания: как писать скрипты, так чтоб их не порвало случайным файлом с «неправильным» именем и как называть файлы, чтобы они не вызывали проблем для кривых скриптов — всё это можно выкинуть на помойку. При этом цена за такое счастье невелика:

#!/usr/bin/env bash

echo Мои книги:

for file in `ls *.txt`; do
    echo $file
done

#!/usr/bin/env bb

(require '[babashka.fs :as fs])

(println "Мои книги:")

(doseq [file (-> (fs/list-dir "." "*.txt") )]
  (-> file fs/file-name println))

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

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

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

echo Мои книги:

ls -1 *.txt | while read; do
    echo "$REPLY"
done

же надо было read-ом, он кушает построчно

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

Второй код мне не понятен.

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

Ссылка что-то не открылась.

Существует огромный пласт знания как ходить по минному полю и не подорваться.

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

Тогда зачем программисты вообще на нём программируют, есть же всякие перлы и питоны?

Ссылка что-то не открылась.

У меня открывается. Должно быть блокировки какие. Неважно, у меня есть другая.

есть же всякие перлы и питоны?

Хороший вопрос. Целого ответа у меня нету, но могу предложить кусочки:

1. Раньше на перле скриптов разных было написано немеряно, но потом перл как-то резко закончился.

2. Скриптописание как-то тоже окукливается и выходит из моды. Чем переписывать шелл-лапшу на питоне, сейчас сразу возьмут Ansible (который на питоне и делает то же самое, но более предсказуемым образом).

3. Возможность строить трубопровод из ехал grep, через sed, сунул sed в awk свой вывод, а там на конце gzip сидит — это очень крутаая возможность. Без неё грустно. На замену предлагаю похожую штуку.

Собственно (-> file fs/file-name println) имеет схожую семантику с pipe’ом. Значение переменной file (объект) поступает на вход функции fs/file-name, которая из него делает строку-имя файла и отправляет дальше функции println которая уже отправляет её на печать. Точно так же можно было бы входы-выходы у внешних скриптов увязывать. Получается всё равно многословнее, чем в bash, но тут уж ничего не поделаешь. Приходится терпеть.

Babashka is written for developers who are familiar with Clojure on the JVM.

Хорошее начало 🤣

Функциональный лисп-подобный бла-бла-бла. Бро, это не для домохозяек, мне так не пойдёт. Шелл-то для простых смертных писали.

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

Кстати, а почему тогда не guile используешь? Ведь он как положено гнутый и везде наверное есть.

Как не испольую? Использую. У меня на нём guix написан. Но clojure даёт выход сразу на все библиотеки для явы. А это прямо очень вкусно. Можно взять лучшее из двух миров: нормальную платформу, чтоб не писать с нуля поддержку всех форматов и протоколов и могучий язык, с нормальным repl’ом.

Круто! Но я не из ваших, мне не понять.

Ха, прикинь, оказывается for надёжно работает с именами файлов и

for file in *.txt; do
    echo $file
done

сделает красиво и ничего не надо городить.

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

$ ls *.txt
'file 1.txt'  'file 2.txt'  'file 3.txt'

$ ls *.txt > files; cat files
file 1.txt
file 2.txt
file 3.txt

Признаюсь, я нарочно выбрал такой выпуклый пример. Так-то у баша (как и у C++) есть типовые решения, как делать правильно, а неправильно не делать, чтобы не было проблем. Но не проверять же методом внимательного взгляда все скрипты, с которыми приходится работать. Это вне сил человеческих. Так что мне видится логичным перейти на более высокий уровень.