Shell, Perl

[Ivan Shmakov <oneingray@gmail.com>]

>>>>> "AC" == Artem Chuprina <ran@ran.pp.ru> writes:
>>>>> Артём Н.  @ Sun, 01 Jul 2012 14:35:40 +0400:

[…]

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

 AC> Package: perl-base

 AC> Priority: required

 АН> o.O Perl, кажется, похож на автомат со снятым предохранителем,
 АН> направленный в ноги?

 AC> Многое зависит от наличия головы ;-)  Никто не мешает писать в
 AC> каждом перловом файле use strict;

	Возможно даже:

use strict;
use warnings;

	Авторы use common::sense, впрочем, утверждают, что use warnings
	слишком уж требователен к ресурсам.

 AC> и даже запускать его с -T.  Ну и эта...  Все его "короткие"
 AC> варианты под девизом Do The Right Thing - они для однострочников.
 AC> В скриптах, от которых требуется надежность, никто не запрещает
 AC> использовать более многословные варианты,

	В частности, use English.

 AC> и даже иногда что-нибудь проверять :-)

	Еще можно вспомнить возможность разделить единственный файл
	исходного кода на несколько модулей, подобно:

package My::Foo;

# Code

package My::Bar;

# Code

package main;

# Code

	Бывает полезно с точки зрения предотвращения доступа к «чужим»
	переменным.  (И упрощает последующее выделение кода в отдельные
	пакеты для размещения на CPAN.)

	И да, как мне кажется, я все же научился писать читаемый код на
	Perl.  Изучив Scheme.

[…]

 АН> Так причём тут проверка в конфиге?  Достаточно проверки в
 АН> загрузчике конфига:

 AH> config:

 АН> OPT_PARAM1=123

 АН> Скрипт:

 АН> . config
 АН> OPT_PARAM1=${ENV_USER_PARAM1-:OPT_PARAM1}

 AC> Можно.  Но обычно удобнее в конфиге написать

 AC> OPT_PARAM1=${OPT_PARAM1:-value1}

 AC> и позволить пользователю переопределять именно OPT_PARAM_1,
 AC> использование которой он потом увидит, а не неочевидно с нею связанную
 AC> ENV_USER_PARAM1

	BTW, есть и более короткий вариант:

: ${VARN:=VALUE}

[…]

-- 
FSF associate member #7257