[Top][All Lists]

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

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

From: David Allouche
Subject: Re: [Gnu-arch-users] Features command for arch
Date: Mon, 30 Aug 2004 11:17:27 +0200

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: 

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".

> $ 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:




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.

> $ 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

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.

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.

                                                            -- ddaa

reply via email to

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