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

[anatoly techtonik]

On Tue, Feb 19, 2013 at 12:12 AM, Eric Blake <address@hidden> 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.