GNU bug report logs - #13737
Add -h option to 'users'

Previous Next

Full log

Message #30 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: anatoly techtonik <techtonik <at> gmail.com>
Cc: 13737 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 13:57:59 -0700

[Message part 1 (text/plain, inline)]

On 02/18/2013 01:31 PM, anatoly techtonik wrote:
>> We HAVE documented it.  We document that ALL long options can be
>> represented by an unambiguous prefix, so --h is an unambiguous prefix of
>> --help if there are no other long options beginning with h.
> 
> Is it a part of POSIX, RedHat or just usual man page for 'users'? Can you
> post a proof link here?

Long options are not specified by POSIX.  But they are commonly
implemented by getopt_long(), which documents the GNU-standard behavior
of recognizing unambiguous prefix.  The glibc manual doesn't document
prefix handling (arguably a bug in glibc documentation, but that is not
a question for this list):
https://www.gnu.org/software/libc/manual/html_node/Getopt-Long-Options.html#Getopt-Long-Options

but the Linux man pages DO document abbreviations:
http://linux.die.net/man/3/getopt_long
"Long option names may be abbreviated if the abbreviation is unique or
is an exact match for some defined option."

Coreutils also documents it here:
https://www.gnu.org/software/coreutils/manual/coreutils.html#Common-options

which is very near the beginning of 'info coreutils', our preferred
documentation system.

> 
> Do I understand it right that if OpenBSD implements "-h" - you'll copy?

Yes, if there is existing practice of burning '-h' to mean help in some
other implementation, then the option cannot be standardized by POSIX to
mean anything else, so we might as well also make it mean help.  But we
aren't going to lead the pack on burning a short option for something
like help.

> And what if OpenBSD says that "unless GNU implementation"?

Good for them.  Burning short option letters is not something you want
to do lightly.

> 
> I don't get why GNU development and usability features should depend on
> non-GNU implementation?

GNU prefers long options.  We support short options insofar as standards
documents and compatibility dictate, but don't let short options drive
development.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.