[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why aren't gnu utils normalized?
From: |
Barry Margolin |
Subject: |
Re: why aren't gnu utils normalized? |
Date: |
Wed, 02 Sep 2009 21:07:20 -0400 |
User-agent: |
MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) |
In article <d469wfrt.fsf@mailinator.com>,
Bob Fry <bobfry@mailinator.com> wrote:
> >>>>> "MB" == Miles Bader <miles@gnu.org> writes:
>
> MB> One part of the GNU coding standards is a list of existing
> MB> command-line options; if you write a new program or add a new
> MB> option, it's a good idea to try and find an existing option
> MB> which fits, and use that.
>
> Ha! I never looked at it; but it includes this:
>
> "One of the advantages of long-named options is that they can be
> consistent from program to program. For example, users should be able
> to expect the "verbose" option of any GNU program which has one, to be
> spelled precisely `--verbose'."
>
> Though the wording and the example don't fully explain things.
> "*They* can be consistent..." What is *they*? Merely the spelling, or
> also the functionality?
>
> So *maybe* one of the uses of the long-named options is what I am
> proposing...it just hasn't been implemented yet.
The idea is that IF two programs have a similar feature, long option
names allow them to be invoked with the same option name, since there's
not likely to be a conflict problem like there is with single-letter
options.
But this doesn't imply that all programs should have similar features.
It's still up to the program designer to decide which features are
appropriate to it.
Furthermore, not that it says that the options "can be" consistent, not
that they "must be". There's nothing ensuring that when two programmers
are devising similar features for their programs that they'll
communicate with each other and agree on an option name. There are some
options that are very common, like --help, --version, --verbose, but
with less common options there's no central registry to guide
programmers. Programmers are encouraged to try to be consistent with
other programs when appropriate, but if there are multiple precedents
then different programmers may choose to follow different ones.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***