Bash или Python для обвязки: что где удобнее

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

Переписывать на питон или дожимать оболочку? Интересует именно граница: где заканчивается удобство одного и начинается удобство второго.

Граница проходит по данным. Пока скрипт двигает файлы и запускает процессы, оболочка вне конкуренции, у неё это родной язык.

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

Добавлю по своему опыту. Язык тут вторичен, больнее всего бьёт отладка.

Скрипт на sh в триста строк падает молча и в неожиданном месте, потому что по умолчанию он едет дальше после любой ошибки. Первое, что вписывают в любой такой скрипт длиннее экрана:

set -euo pipefail
IFS=$'\n\t'

Без этих двух строк ваши триста живут своей жизнью и вы про это узнаёте по кривой выгрузке.

а что делает pipefail? у меня и без него вроде падает

pipefail меняет код возврата конвейера. По умолчанию код берётся у последней команды, поэтому вот такая строка считается успешной, хотя первая половина легла:

curl -s https://example.org/spisok | grep -c 'tovar'

curl отвалился, grep честно посчитал ноль совпадений и вернул своё. Скрипт едет дальше с пустым списком. С pipefail код конвейера станет ненулевым, и вместе с set -e прогон остановится.

Дальше места, где оболочка кусается именно на длинных скриптах:

• пробелы в путях: любая переменная без кавычек разлетается на слова;
• пустая переменная в rm -rf "$katalog"/ выносит корень целиком;
• арифметика только целая, среднее время отклика посчитать нечем;
• разбор JSON без jq невозможен, а с jq вы уже пишете на втором языке внутри первого;
• функции возвращают только код, всё прочее едет через вывод и подстановку.

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

Вот это прямо про меня. Шесть вызовов jq подряд, и каждый раз я заново читаю один и тот же файл. Долю отказов пришлось считать через awk, потому что оболочка целочисленная.

Значит, режу пополам?

Именно пополам. Схема, которая у меня прижилась: оболочка остаётся снаружи и делает то, что умеет лучше всех, запуск, замки, перенаправление вывода, коды возврата. Всё, что думает, уезжает в питон и вызывается как обычная команда.

#!/bin/sh
set -eu
flock -n /var/lock/progon.lock python3 -m obvyazka.progon --pachka 500

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

а питон на голом сервере без сети как ставить? у нас закрытый контур

Стандартной библиотеки хватает на девять задач из десяти. urllib, json, sqlite3, csv, concurrent.futures уже внутри, ставить нечего.

Если внешние пакеты всё же понадобятся, соберите колёса на машине с сетью и перенесите папкой, дальше pip install --no-index --find-links. Виртуальное окружение кладите рядом со скриптом, тогда переезд на другую машину сводится к копированию каталога.

о, про колёса не знал, спасибо

И оставьте себе право на однострочник. Половина задач так и остаётся тремя строками на sh, тащить туда питон незачем.

Разрезал за вечер. Снаружи sh на сорок строк: замок, обход трёх поставщиков, вызов питона на каждого, архив и отправка в чат. Внутри питон на двести с небольшим строк, куда уехал весь разбор и подсчёты.

Отладка сразу стала человеческой: падает с внятной трассой и на понятной строке. Заодно set -euo pipefail в оставшемся куске поймал две старые ошибки в первый же вечер.