On 02/18/2013 01:58 PM, anatoly techtonik wrote:

>> This command shows the affected programs:
>>
>>     $ grep -le -h, *.c
>>     chcon.c
>>     chgrp.c
>>     chown-core.c
>>     chown.c
>>     df.c
>>     du.c
>>     ls.c
>>     nl.c
>>     pr.c
>>     sort.c
>>     touch.c

And someday I want to add chmod to the list, as 'chmod -h' acting on
symlinks on BSD platforms makes sense, whether or not the Linux kernel
ever someday adds a meaning to symlink mode bits the way BSD already has.

>>
> 
> ~$ chcon -h
> chcon: missing operand
> Try `chcon --help' for more information.
> 
> 1st is not too serious - user didn't get the help - but the hint is there
>   we can't do anything about it, and it can not be the reason to cancel
> usability improvement
> 2nd is not actual as nothing changed

The problem with using -h to mean --help is that we CAN'T do it
globally, and therefore, we are doing the user a disservice by teaching
them to rely on a crutch that won't always work.  Instead, the user
should learn to use --help, which we CAN do globally.  Supporting ONLY
--help as the preferred way to get help, and as the only way documented
by the GNU Coding Standards as being mandatory for getting help, is
actually a benefit, because end users will learn to use the one thing
that reliably works across all GNU software.

> It will help to keep this focused. The original request was for the 'users'
> command.

There's no point adding it to 'users' without prior art, unless we add
it to all of coreutils, and we've already decided we can't add it to all
of coreutils.  And yes, there ARE cases where POSIX has burned -h to
mean something; 'chown -h' was added in POSIX 2001 but did not exist in
POSIX 1992.  Adding -h to mean help just for the sake of adding it is
best done as an all-or-none addition across coreutils.  On the other
hand, adding it on a per-app basis makes sense if we have a per-app
precedent of some other implementation already burning the short option
for that purpose, as it is then unlikely that POSIX will ever
standardize that short option for anything else.

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