[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Features command for arch

From: James Blackwell
Subject: Re: [Gnu-arch-users] Features command for arch
Date: Mon, 30 Aug 2004 13:40:19 -0400

In lists.arch.users, you wrote:
> On Sat, 2004-08-28 at 12:17 -0400, James Blackwell wrote:
>> There's the easy way to do this, and the hard way to do this. I'm inclined
>> to implement the easy way. The easy way is to in libarch implement a
>> handful of arch_features functions along these lines: 

David Allouche:
> What does "hard way" you have in mind looks like? I'm not asking for a
> complete specification, just a glimpse so we can see where it stands
> with respect to the "easy way".

The hard way would involve some sort of query/answer getup in which one
part of the library would ask the other parts of the library for what it
can and cannot do.

>> $ tla features
>> tla-features-begin
>> file-id-escaping:1
>> archive-checksums:2
>> tla-features-end
>> (always a return code of 0)
> As Andrew pointed, the "tla-features-begin" and "tla-features-end" lines
> are noise.
> For the sake of discoverability, I think we should change the output
> format from:
>     <nickname>:<revison>
> to
>     <nickname>:<revision><white><summary>
> where <white> is one or more tab or space and <summary> is a short
> (limited to 40 or 50 characters) description of the feature in natural
> language, similar to the the synopsises in "tla help", so we have a
> useful "tla features | grep" idiom.

> To simplify scripting, you can also add a "feature --quiet" option to
> omits the whitespace and summary.
>> $ tla features file-id-escaping
>> 1
>> (with a return code of 0)
> Similarly, subsequent lines of output may contain the summary and a
> paragraph-long description of the feature. A --quiet option would yield
> the output you described.

More than I want to do.

>> $ tla features archive-checksums 1
>> (return code of 0)
>> $ tla features archive-checksums 3
>> (return code of 1)
>> $ tla features nonexistant-feature
>> (return code of 1)
> I do not see the need for additional natural-language output in those
> cases.
> The rationale for the additional natural language output is to be self-
> documenting, allow new users to understand what each feature means, and
> allow us all seasoned tla users to find the specific nickname for a
> known feature when there will be dozens of them.

I'm already sold on the "short sentence part". I don't like the
"paragraph" part.

> Of course, this suggestion has little value if developers and
> maintainers are not willing to enforce the quality of the natural
> language descriptions of features.

patches welcome. ;)

James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400

reply via email to

[Prev in Thread] Current Thread [Next in Thread]