LINUX.ORG.RU

стандарт для написания bash-скриптов

 ,


0

3

Спасибо предыдущим советчикам. Команду мы уже расширили, но курсов по bash мы так и не подобрали.

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

Оказывается, set -e устроена очень сложно, поэтому у неё бывают ложноположительные срабатывания. Заканчивается тем, что авторы данного документа не пришли к единому мнению:

Выводы

GreyCat рекомендует не использовать -e, а использовать вашу собственную проверку ошибок. 

rking's советует пользоваться -e, но учитывать грабли. 

geirha's советует должным образом обрабатывать ошибки и не полагаться на ненадёжное set -e.

Также можно вот это прочитать

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

Есть где-нибудь пример такого стандарта, который можно внедрить? Питон прошу не предлагать. В негодности тикля для выполнения функций оболочки я уже сам убедился. Можно в качестве альтернативы рассмотреть просто sh, если он того достоин, но я не в курсе.

★★★★★

sh рассматривать можно и нужно. Более, писать скрипты на чем-либо кроме POSIX shell уже является активным поискои проблем.

Siborgium ★★★★ ()
Ответ на: комментарий от alpha

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

den73 ★★★★★ ()
Ответ на: комментарий от den73

всякие интеграционные тесты и сборочные скрипты сложнее трёх, и зачастую сложнее трёхсот

Поэтому их не пишут на bash, а пользуются тестовыми фреймворками и сборочными системами.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

Ээээ, например, какими? Мне кажется, что станет только хуже - из простой задачи написать скрипт возникнет сложная задача - изучить этот фреймворк, научиться работать в его ограничениях, а потом страдать, когда он выйдет из моды. Про сборочные системы - ну я бы не сказал, что какой-нибудь make прямо так уж удобен для отладки. Декларативный язык. Когда-то я пытался понять, как отлаживать работу make, но мне не понравился ни один из вариантов. Какой-нибудь ant - это вообще ад.

И кроме того, у нас уже есть скрипты, их не так мало. Они документированы, люди к ним привыкли и т.п.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

баш - это как C++

Нет.

Пользоваться им нельзя

И не нужно.

заменить его зачастую нечем

Питон прошу не предлагать.

Тогда твоя судьба - страдать. Говорю как человек, работающий с 300-килобайтным тест-фреймворком на шелле и парой мегабайт собственно тестов на нём же.

suspend ()
Ответ на: комментарий от den73

из простой задачи написать скрипт

А простая она по какому критерию? То что ты который месяц ищешь способ написать из баш-лапши не лапшу - это типа такой критерий простоты?

У тебя изначально задача не написать скрипт, а написать интеграционные тесты к продукту. У этой задачи есть некоторая сложность, в основном завязанная на то что надо понимать как устроены тесты вообще, что такой test case, что такое fixture, и т.п.

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

И называть этот способ «простым» очень странно.

alpha ★★★★★ ()

Питон прошу не предлагать.

Ну, тогда запили на js.

crutch_master ★★★★★ ()
Ответ на: комментарий от garik_keghen

Спасибо! Там не написано, что надо использовать set -e . Вместо этого рекомендуется проверять результат каждой команды. Интересно, а как быть с конвейерами? (И теперь я уже не знаю, как себя в этом случае ведёт set -e - раньше над этим просто не задумывался, т.к. верил в то, что он в любом случае упадёт. А оказывается, не в любом).

Но и про -u не написано - это уже подозрительно. Хотя непонятно, кого тут подозревать - авторов руководства, авторов баша, или всех.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от suspend

Тогда твоя судьба - страдать. Говорю как человек, работающий с 300-килобайтным тест-фреймворком на шелле и парой мегабайт собственно тестов на нём же.

И как ты отлаживаешь это?

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от Siborgium

писать скрипты на чем-либо кроме POSIX shell уже является активным поискои проблем

Топикстартер, прислушайся к мудрому элементу! Он истину вещает!

mord0d ★★★★★ ()
Ответ на: комментарий от suspend

И как ты отлаживаешь это?

Ну как, стиснув зубы. Главным образом, я стараюсь его НЕ отлаживать.

Может тебе это будет полезно, хотя я сам не пробовал: https://stackoverflow.com/a/17734099/9469533

Вывод стека выполнения bash-скрипта. Можно попробовать совместить с trap и EXIT, чтобы при падении высыпался стек, а также с -e, чтобы падало при любой неясности.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

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

mord0d ★★★★★ ()
Ответ на: комментарий от Siborgium

sh это обычно симлинк к dash, bash или (гораздо реже) ash.

 % readlink -f /bin/sh
/bin/sh
 % ls -l /bin/sh
-r-xr-xr-x  1 root  wheel  uarch  165K 2019-11-04 23:53 /bin/sh*

Никаких симлинков. :3

mord0d ★★★★★ ()
Последнее исправление: mord0d (всего исправлений: 1)
Ответ на: комментарий от den73

А там есть аналог -e ?

Если ты про set -e, то да, ибо IEEE 1003.1 (оно же POSIX.1).

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

mord0d ★★★★★ ()
Ответ на: комментарий от den73

Вывод стека выполнения bash-скрипта. Можно попробовать совместить с trap и EXIT, чтобы при падении высыпался стек, а также с -e, чтобы падало при любой неясности.

Вообще стандартная схема для всех инфровых скриптов: set -ex второй строкой после shebang.

alpha ★★★★★ ()
Ответ на: комментарий от den73

Потому что фреймворки надо искать в гугле под свои навыки и задачи.

alpha ★★★★★ ()
Ответ на: комментарий от den73

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

garik_keghen ★★★★★ ()

Хочель баша и стандарт - заморозь его (баша) версию для своих скриптов

ananas ★★★★★ ()
Ответ на: комментарий от den73

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

Удваивать количество кода? Да ну нах.

Интересно, а как быть с конвейерами?

set -eo pipefail

Но это именно bash, not sh.

debugger ★★★ ()
Ответ на: комментарий от den73

Гуру тебе пишут «Shell should only be used for small utilities or simple wrapper scripts.» Желающего в угоду своим тараканам делать на баше фреймворки и метапроги - никакие практики не спасут.

pinus_nigra ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей