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