On Tue, Feb 19, 2013 at 12:12 AM, Eric Blake <eblake@redhat.com> wrote:
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.

I see - the BSD implementation is the only alternative. It is possible not to touch chown/chmod then. Can we add BSD folks to the discussion?
 
>>
>
> ~$ 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.

You forget that there are thousands of commands that don't belong to coreutils. In these commands "-h" works ok, so it is impossible to teach users anythings, but easy to make them suffer instead every time they forget which commands belong where.

I don't know which commands are GNU software and which are not. I use "-h" as a intuitive way across different systems, and in Linux it doesn't work, particularly with 'users' command. Now you're saying that "-h" can not be added to 'users' because 'chown' on BSD already has it. I am overreacting, but hopefully you see the problem.
 
> 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.

Can you please explain this 'prior art' argument? I suspect that you insist on solving this 'generic way'. Otherwise I miss the link between 'users' as a system command and 'coreutils' as a bunch of commands. Let it put this way - each command has it's own arguments. Some arguments may match. Why do you need to add these argument to the rest of commands?

I still can't see why you can't add "-h" to the commands that don't have it.

I provided arguments, but so far I miss the counter-arguments. The argumentation "we've already decided" comes as a surprise - my thought was actually that I provided enough reasons to say the points against are not valid without some research. Probably we need to make a list of conflicting points and it will be better if you could make a summary of that, because I am starting to get lost.
 
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.

It is not for the sake of adding it. It is for making unix commands easier to use for unix users, who can't remember the syntax for those commands. It is an important accessibility feature, and it should not be "all-or-none". Moreover, it could not be "all-or-none", because POSIX hackers already missed that use case for some commands.
 
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.

You need implementation of some command from other implementation of 'coreutils' package? I doubt that it can happen if there are only two known implementations of coreutils which try not to break each other, unless they communicate rather freely.

If it is a matter of just system app precedent, then any system script written in Python + optparse will have "-h" option provided by default http://docs.python.org/2/library/optparse#generating-help I am not an expert in Linux system commands, but I guess Ubuntu has the biggest chance for having that.