Re: [devel] hasher is lacking black box properties

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

On Thu, Mar 03, 2011 at 02:54:46AM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 02, 2011 at 05:28:57PM +0200, Igor Vlasenko wrote:
> > наш hasher не является черным ящиком: вход у него есть,
> > и скрипт может подать туда что-нибудь,
> > а вот описания выхода ему не хватает --
[...]
> > Это поправить легко, надо только добавить к нему интерфейс
> > описания того, что на выходе.
> > 
> > Мое предложение -- опция --reportdir=/path/to/reportdir 
> > к hsh, и, возможно, другим утилитам.

> Мне кажется, что и одного файла было бы достаточно, чтобы рассказать
> обо всем, что может быть интересно.  
 
eсли давать вредные советы, то да, один большой файл, и еще 
желательно в xml, чтобы был полный ЫнтЫрпрайз :)

Сходу, как правило, в голову лезут быстрые неправильные решения. 
Я не вас критикую, я себя критикую -- в баге #, если вы 
обратили на него внимание, я вообще предлагал вам утилиту 
hsh-env. Но когда я ее написал, то увидел, что и реализация
уродлива, и, что еще хуже, уродливо ее использование 
в скриптах из-за необходимости проверять код завершения.

Немного остыв, подумал о --reportfile=file.

> Если нет, то просьба привести контрпример.

Я тогда как раз себе и привел контрпример --
в отчете нужны разные денные -- списки
(собранных пакетов, напимер) и переменные.

распишу на этом примере, какие видятся недостатки.

отчет нужен для использования в скриптах, в т.ч. в shell
скриптах. Поэтому его формат должен быть дружественным к скриптам,
по этой причине xml, ini, conf не желательны.

Но в отчете должны быть разнородные данные.
списки файлов и значения переменных.

Можно, конечно, извратиться, например, завернуть список файлов в
переменную. Но зачем извращаться, при чем недружественно к
скрипту, которому придется ее разворачивать?
Можно попытаться все завернуть в один файл, но вот при попытке 
это все развернуть в скрипте пользователя вылезет куча подводных
камней с разделителями, кавычками, квотированием и максимальной
длинной строк.

Логичнее было бы отделить мухи от котлет и хранить 
хорошие списки как текстовые списки, 
плохие списки как null-terminated string lists,
значения переменных - как угодно, но в жестко описанном
формате: например, 
<<variable_name=value.. без кавычек и экранирования, без пробелов
вокруг разделителя "=", для получения значения переменной
воспользуйтесь стандартной grep/sed или awk конструкцией>>
но для этого их придется развести по разным файлам,
отсюда и каталог отчета.

И не будет проблем с расширяемостью отчета -- старые файлы будут
следовать старым соглашениям, а не так, что пришлось добавить
кавычки или экранирование и все старые скрипты сломались.

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

человеку с головой хватит и |& tee log в конце.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine