bug-coreutils
[Top][All Lists]
Advanced

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

bug#13737: Add -h option to 'users'


From: Eric Blake
Subject: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 13:57:59 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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