[Top][All Lists]

[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 <>,
 Bob Fry <> wrote:

> >>>>> "MB" == Miles Bader <> 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
> 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 

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,
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 ***

reply via email to

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