У меня в ff не тормозит, чини кром.

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

Использовать systemd.

/thread

а не проще ли использовать встроенные языки (perl, python и т п) ?

ff тормозит сам по себе.

Каноничные 5 строк

Паазвольте! Во-первых, а Fatal()? Во-вторых, на кой надо было local tool=$1 ?

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

Это ерунда по сравнению с тем, что оно что-то сделает и вывалится на половине, а потом вычищай то, что испохабилось наполовину.

Во-вторых, на кой надо было local tool=$1 ?

Для самодокументированности. Именованных параметров-то в функции не завезли. А строчек мне не жалко, у меня хороший текстовый редактор.

Это ерунда по сравнению с тем, что оно что-то сделает и вывалится на половине, а потом вычищай то, что испохабилось наполовину.

Надо ERR трапать, вот кстати осталось неизвестно сделал ли это ТС.

Я один такой?

Нет, вполне естественное желание. Сам себя ловил на таких вещах неоднократно. Ну и примеры выше в обсуждении.

Считаете ли вы такой подход правильным?

Нет.

Скрипты — это принципиально throwaway–код. Из них не надо делать программы, их не надо поддерживать. Просто потому, что это нерентабельно по время– и трудозатратам. Если скрипт не работает, он выкидывается и пишется новый скрипт.

Нужно просто принять тот факт, что shell — очень плох в качестве языка программирования. Это скорее «синяя изолента», средство для склеивания ввода–вывода нескольких утилит, и должно применяться соответственно — для однострочников и мелкой автоматизации.

Если возникает необходимость в сложной логике, в обработке ошибок, в переносимости — нужно сразу брать нормальный язык программирования — пусть даже интерпретируемый, навроде Python, Perl, Ruby или Lua. Или сразу на сишечке, чтоб не мелочиться.

А то и вовсе посмотреть в сторону систем автоматизации сборки (make, CMake и подобные), или даже управления конфигурациями (Chef, Ansible, etc) — в зависимости от того, какая задача стоит.

Надо ERR трапать,

Речь о том, что это полдела, ибо надо знать ВСЁ, что сделал скрипт до ошибки.

Зависит от назначения рукожопства:

Если «для себя» (для своей конторы, etc), то смысла нет.

Если «на продажу» (дарение, выкладку, etc), то всё проще решается:

в первых строках скрипта задаю утилитки с путями в виде переменных, а потом для работы использую из вызов через переменную, типа:

_____

#!/bin/bash

CAT_UTIL=«/bin/cat»

TEMP_FILE=«/tmp/tempfile»

$CAT_UTIL $TEMP_FILE

_____

Если уж будет ну НАСТОЛЬКО нестандартный дистр, то руками подправят пути.

Считаете ли вы такой подход правильным?

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

Следуя принципу «чтобы работало везде» я его раздул до 350 (!). Там было всё: проверка наличия необходимых утилит в системе,

Считаю, такой подход неправильным.

1. Если что-то пойдёт не так (а всё ты не учтёшь), то никто не будет разбираться с твоим монстром в 350 строк. Пусть будет 5-10 строк, но понятных и документированных. Тогда есть шанс, что твой скрипт легко модифицируют под конкретику.

2. ИМХО, 95% твоих проверок ни разу не выстрелят, т.е. ты отработал впустую.

3. У меня обычно имеет место обратный процесс, сначала скрипт на страницу, а затем он «усыхает» до нескольких строк. Но во всём должна быть мера - скрипт не должен допускать трюкачество и оставаться понятным.

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

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

Комментарии, системные требования и справка

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

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

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