From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_OPENWHOIS,SPF_PASS autolearn=no version=3.2.5 Date: Thu, 3 Mar 2011 22:03:03 +0200 From: Igor Vlasenko To: ALT Linux Team development discussions Message-ID: <20110303200303.GA29645@dad.imath.kiev.ua> References: <20110302152857.GA15878@dad.imath.kiev.ua> <20110302235445.GE7212@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110302235445.GE7212@altlinux.org> User-Agent: Mutt/1.5.20 (2009-08-17) Subject: Re: [devel] hasher is lacking black box properties X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:03:09 -0000 Archived-At: List-Archive: List-Post: 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, значения переменных - как угодно, но в жестко описанном формате: например, <