Когда имеет смысл использовать bash...

Когда надо работать со сложными структурами данных, а не гонять потоки по пайпам

Куча скриптов это всегда боль. Хоть на баше, хоть на питоне, какая вообще разница.

Да, но, к примеру, сопровождение кода, где процентов 40 это вызовы библиотек, и кода, где почти все это код баша - две разницы. К примеру, у меня сейчас много обработки yaml, зачем ее сделали на баше неясно. Но это боль

А, там аж настолько все круто? Тогда да, упрощать, конечно.

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

• Если в скрипте надо писать много условий и циклов, а не просто команды и пайпы.
• Если скрипт превышает условный лимит в 100 строк (каждый определяет его сам для себя). Или есть подозрение, что в будущем скрипт разрастется и превысит лимит. Поддерживать огромные портянки на баше - это всегда боль и страдания.
• Если в скрипте надо работать со структурами данных. Да, в баше есть как простые, так и ассоциативные массивы, но работать с ними - такое себе удовольствие.

Если же решил все-таки писать скрипты на баше, то и в них надо соблюдать хорошие практики программирования. Например следовать Google Shell Style Guide, разбивать код на функции, давать читаемые имена параметрам функций $1, $2…, использовать локальные переменные и константы (команды local, readonly, declare), тщательно следить за использованием кавычек, чтобы скрипт не ломался на путях с пробелами и т.д. Писать код лучше не в блокноте, а в IDE, использовать bash language server, shfmt для форматирования, shellcheck для статического анализа. Например вот неплохая статья по настройке Visual Studio Code. Все то же самое можно организовать и в виме, и в емаксе.

https://habr.com/ru/articles/583320/

Спасибо большое, давно искал подобное!

Если ты админ то наверное лучше вообще какой-нибудь анисиёбл использовать в 2k23.

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

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

Поддерживать энтерпрайзные портянки на node.js, java или старинном си, где все обмазано дефайнами, вот где боль. Питон, к стати, тоже боль, но в другом месте.

На bash реализован сборочный механизм пакетов в Arch. mkinitcpio для генерирования initramfs тоже реализован на bash.

Вот для таких задач bash подходит.

Если же в задаче нужно «парсить yamp», то что-то явно было сделано не так. Можно было взять python или ruby и не пытаться забивать гвозди отвёрткой.

Когда имеет смысл использовать bash…

когда нет стандартных, (хорошо) документированных, сопровождаемых решений.

правило номер 1 - никаких велосипедов на баше.

правило номер 2 - все, что написано на баше - велосипед

Если надо в базу добавить пару строк или грепнуть что-нибудь нетривиальным запросом. На баше делается проще всего. Нормально документируется и расширяется.

Язык логичный, стройный и по всем канонам unix.

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

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

Шел скритпы могут быть неприятны только если ты виндузятник и не умеешь в программирование и логику ну вот совсем.

Шелл скрипты могут быть неприятны, если ты хотя бы немного умеешь в современные языки программирования и краем уха слышал про хорошие практики разработки. Ты точно писал хоть что-нибудь сложнее хелловорлда на питоне или джаве? Довольно странно сравнивать более-менее современные ЯП общего назначения с нетипизированным процедурным копролитом из 70-х, предназначенным для решения задач из своей узкой ниши.

Главное преимущество шел скриптов — скорость написания и простота. Если тебе нужно быстро решить задачу причем не важно насколько быстро будет выполняться код, шел тут в радость. И не важно какой структуры данные ты парсишь. Бывало что даже выполнить запрос в БД и распарсить результаты намного проще и быстрее на шеле чем на любом другом ЯП. Даже если тебе нужно вытащить строку или слово из файла определенной структуры, пускай yaml или xml, то быстрее и проще чем grep ... file | awk '{print $2}' ничего нет. Если логика становится сложнее, то тогда есть смысл написать на чем-либо другом, что будет удобнее в этом конкретном случае.

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

Открой скрипт, если он для тебя понятен – зачем его переписывать? Оцени задачу, которую он выполняет, как ее проще реализовать, на баше или питоне?

Если скрипт не длиннее 100 строн, то на баше.
Если длиннее, то баш уже не подходит.

Язык логичный, стройный и по всем канонам unix.

Это говно какое угодно, но не логичное и стройное:

if
then
elif
else
fi

case in
esac

while
do
done

for
do
done

Сопровождение портянок на «языке программирования» in general гораздо большая головная боль, чем сопровождение портянок на условном «баше» (ака любой скриптовый язычок), потому что для последних тебе нужен только текстовый редактор, а для первых - усраться.

Как только появляются структуры данных сложнее списка, логика сложнее обычного if/case, функции с множеством аргументов и проверок и подобные сложности, лучше брать perl/python. Но для огромного количества типовых задач вполне себе достаточно шела. Плюс шела в том, что он простой, понятный и есть везде. И к нему нет необходимости искать и ставить всякие хитрые библиотеки(ещё и конкретных версий зачастую).

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

Пример. Надо сходить в какую-то апишку и получить json. А далее два варианта: распарсить json, и с его аргументами вызвать надцать утилит - шелл; распарсить json, обработать с результатами собрать другой json и плюнуть назад в апишку - perl/python/etc.

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

Никогда /thread

perl5_guy

анисиёбл

/0

Баш юзаю максимум для пакетного запуска команд. Всё остальное консольно-скриптовое пилю на Ruby, понравилось когда-то. Тыкал веточкой перл и питон для этих целей - как в анекдоте «нЭ хАчу».

Bash хорош когда:

• у тебя много вызовов внешних команд
• ты не работаешь со сложными структурами данных (массивы, структуры, json)
• размер до 500 строк

Как правило это admin/devops задачи, хотя и не обязательно.

Если кажется что bash подходит, но мы выходим за рамки перечисленного выше, то имеет смысл посмотреть в сторону Python.

Python хорош когда:

• написание кода не есть целью, а скорее средством решения другой задачи. Например devops, QA, data scientist и т. п.
• нужно быстро сделать небольшой PoC перед тем, как ввязываться в нормальную разработку.
• новичку нужно научиться программированию с нуля (раньше этот сегмент занимал Pascal).

Основное достоинство Python - там есть библиотеки на любой вкус.

Java - идеальный баланс возможностей и порога входа. Плюс большой спрос на рынке труда. Идеален для тех кто хочет быстро «войти в IT» и зарабатывать на жизнь программистом, и при этом не WEB. Но имеет ряд ограничений. Например, вселяет необоснованную веру фреймворки и автоматизации, которая разбивается когда возникают такие проблемы, как, например, утечки памяти (мне ж обещали что их не будет!) или когда друг знающий SQL предлагает решение которое работает 3 секунды, в то время как твое решение на Hibernate падает по timeout. Также не самый лучший выбор для контейнеров, ибо приложения получаются ресурсоёмкими и долго стартуют, в сравнении, например, с теми же C, C++, Golang.

С# - не имел с ним дела, но, как я понял, эквивалентен Java.

Если WEB - JavaScript, естественно в комбинации с HTML и CSS. Не знаю как с php, вроде как его сейчас принято хейтить, но пусть другие подскажут. Мне кажется имеет смысл хоть немного ознакомиться.

Си:

• небольшие нативные приложения с CLI или TUI (то есть без GUI); например, утилиты Linux
• когда требуется максимальная скорость или минимальное потребление CPU, памяти
• системное программирование, прошивки и т. п.
• нет работы с UTF и text-based форматами данных (json, yaml и т. п.)
• требует понимания как именно работает программа. Если вы хотите быть senior девелопером, неважно какого языка, вы точно должны уметь на Си.

Вообще, Си - самый универсальный язык.

Assembler - когда нужно использовать низкоуровневые возможности железа, например SSE, MMX и т. п. инструкции процессора для оптимизации вычислений.

С++:

• по возможностям сопоставим с Java, если не круче
• очень высокий порог входа (в отличии от Java). Притом тут опыт значит больше чем знания. Здесь одно и то же можно сделать 100500 способами, и если выбрать неверно, то будет беда. То есть тут нужно иметь компетенцию аналогичную Си + Java и даже больше. Зато после этого любой язык будет осваиваться на раз.
• оптимально по ресурсам - от отличии от Java, и как в Си
• можно писать большие проекты, в том числе с GUI - в отличии от Си.

С++ - это очень серьёзный уровень.

Rust - не имел с ним дела, но как мне кажется, это С++ без некоторых его недостатков.

Golang - точно нужно знать если работаешь c Kubernetes. Либы для Kubernetes лучше всего представлены именно здесь. Например, helm, operator SDK и т. п. Шустрый, хорош для контейнеров. Но, как по мне, не лишён странностей: например, зря они отказались от исключений.

Всё вышеизложенное - моё личное ИМХО, не претендующее на вселенскую правду.

… ты не работаешь со сложными структурами данных (массивы, структуры, json)

Это не совсем аргумент - поддержка примитивных массивов в bash-е имеется, для работы с json вполне можно задействовать утилиту jq, ну и естественно curl для REST. Программировать подходящие задачки на bash можно не менее надежно, чем на том же питоне - просто не надо злоупотреблять цепочками пайпов: получил STDOUT очередной команды и её код завершения, разобрал STDOUT по переменным (например, выхлоп curl-а) и пошел дальше. Ну т. е. обычный процедурный язычок программирования.

В качестве своего последнего примера выбора именно bash-а могу привести задачку сохранения бэкапов БД в storage-корзине облачной платформы, выполняемую в контексте контейнера Kubernetes. В AWS просто использовалась утилита aws, поскольку она оформлена в виде статичного бинарника относительно небольшого размера - спасибо разработчикам Golang:) Но вот в Azure утилита az уже написана на питоне и при установке разворачивается на полгига :) Пихать такое в контейнер ради двух REST-обращений я как-то не смог - душа воспротивилась. Просто написал bash-скриптец для сохранения файла в корзине Azure Blob Storage, который вообще деплоится в контейнер через кубовский Secret-объект (как и другие вспомогательные скрипты). Все замечательно пашет и очень удобно в сопровождении. Обновление Letsencrypt-сертификатов в кластере тоже оформлено на bash-е. Хотя это уже более сложная задачка, но bash её вполне потянул. Нет проблем при смене DNS-провайдеров (уже на третьего перескочил) - просто пишется соответствующий плагин.

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

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

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

А почему «обфусцированные»?

Всё так, но…

Я когда-то на bash написал автоматизацию тестирования одного приложения. REST, массивы, JSON, over 1000 строк. Всё работало как часы. И после этого я начал учить Python. Потому, что на Python это делается проще. И поддерживается проще. Пока скрипт небольшой - это плюс-минус одинаково. Но вот когда большой - это уже существенный фактор. 500 строк - очень примерная цифра, она скорее о порядке, чем о конкретном количество строк.

…Потому, что на Python это делается проще. И поддерживается проще.

Ну тут многое зависит от реальных задач. Выбор конкретного языка не всегда связан с «простотой» программирования. Иногда, к примеру, более важна доступность - в том же контейнере - или компактность. Если глянуть на контейнерные скрипты docker-entrypoint.sh, то они все на bash-e.

Конечно, если кодить что-то более крупное и не связанное с «оберткой» вокруг CLI-утилит, выполняющих основную логику, то язык нужно выбирать повыше и со стандартной библиотекой.

Есть какие-то индикаторы, что изначально стоит писать не на баше?

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

Главное преимущество шел скриптов — скорость написания и простота.

А также тот момент, что не надо устанавливать ни интерпретатор, ни вагон и маленькую тележку необходимых ему библиотек. Причём на установку дополнительных пакетов часто и прав нет, для shell'a джентльменский набор из всяких ls, ps, grep, tail, awk чаще всего присутствует из коробки

Если скрипт не длиннее 100 строн, то на баше.
Если длиннее, то баш уже не подходит.

Про игры на bash не слышали? :)

старинном си

Откуда у этой мудрости что-то растёт…

Нескрипты тоже устареют

Хорошо сказано!