Re: Несколько вопросов вразброс

[Artem Chuprina <ran@ran.pp.ru>]

Артём Н. -> debian-russian@lists.debian.org  @ Sat, 30 Jun 2012 12:44:37 +0400:

 >>  >> Ну, все-таки в шеллах традиционно используют . /path/to/config и
 >>  >> отдельный префикс для "своих" переменных.  Зачитывают обычно не в каждой
 >>  >> функции, а один раз на скрипт.
 >>  АН> К чему, в итоге, я и пришёл.
 >>  АН> Ассоциативный массив - это замечательно.
 >>  АН> Но поддерживается только Bash. :-(
 >>  АН> А шелл, по умолчанию, всё-таки dash. Не хочется полагаться на "башизмы".
 >>  АН> И ещё в dash нет $LINENO и $FUNCNAME, что печально... :-(
 >> Ну, шелл вообще не очень хороший инструмент для создания надежных
 >> систем.  Он не для этого предназначен.
 АН> Однако, немалая часть ОС его использует...
 АН> Зачем нужна любая система, которая ненадёжна?

Вот у тебя там выше по треду было "если один файл в бэкапе побился, то
проще выкинуть весь бэкап".  На практике это не так.  Ценность остальных
обычно довольно высока.  Вот скажем, у меня на одной из работ
электростатика такая, что неудачно коснувшись клавиатуры недобука, можно
огрести полный завис системы.  При каждом таком зависе обычно fsck
находит и удаляет несколько orphaned inodes (т.е. файловая система
оказывается битой).  Ценной информации при этом не потерялось ни разу.
Стоит ли ему, обнаружив один orphaned inode, удалять всю файловую
систему нафиг?

Так вот, система обычно нужна в первую очередь выполняющая свои функции.
Может быть, с огрехами, но выполняющая.  Надежность - требование никак
не первое, и скорее всего, не второе.

Система, при подъеме которой несколько скриптов обломались, обычно
все-таки поднимается, и можно что-то сделать с полученным
недорезультатом.  А зависимостей у шелла, особенно какого-нибудь
статически собранного dash - минимум.  Соответственно, шансов получить
надежную, но не загружающуюся систему, тоже минимум.

 АН> Уж, если оффтопить, то по полной. :-)
 АН> Что для создания надёжных систем больше всего подходит?
 АН> И практически применимо (по опыту)?

Любой язык с полноценными ручками к fork/exec и обработкой исключений.
У шелла, собственно, первое есть - второго нет.

Я скрипты, от которых хочу надежности, обычно на перле пишу, учитывая,
что в Debian

Package: perl-base                       
Priority: required

(ну, надо помнить, что там ограниченный набор модулей, но все же).

 >>  >> Зачастую еще прикрыв проверкой на
 >>  >> определенность переменной вроде
 >>  >> if [ -z "$MY_VAR" ]; then . /path/to/config; fi
 >>  АН> Чтобы пользователь мог переопределить переменные перед запуском скрипта?
 >> Нет, чтобы решить, что конфиг уже читали.
 АН> Типа #ifdef x/#define x? А зачем, если он читается один раз?

На случай, если прочитать забыли.  В "библиотечном" скрипте.

 >> Чтобы пользователь мог переопределить - это надо внутри конфига делать
 >> подобные проверки.  На предмет чего у шеллов (у всех sh-derived) есть
 >> прекрасная подстановка ${parameter:-word}, чтобы так длинно не писать.
 АН> Почему внутри конфига?

Чтобы пользователь мог переопределить одну из пятнадцати переменных,
определенных в этом конфиге, а в остальных четырнадцати положиться на
конфиг.