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

[anatoly techtonik]

On Mon, Feb 18, 2013 at 11:01 PM, Bob Proulx <address@hidden> wrote:

> Jim Meyering wrote:
> > One more point: a long time ago, I too thought about adding -h
> > as an alias for --help for these 100-or-so programs, but even then,
> > there were numerous commands for which -h was already accepted,
> > but with a different meaning.
>
> Yes.  That is also an issue.  Because -h is so often already used for
> other things.
>
> > Thus, we cannot do it across the board, and
> > that was another reason not to do it.
>
> Agreed.
>

3/4 people from this discussion had the same idea of usability improvement.
That's 75% and 2 of them are hardcore hackers, who don't need this option.
The necessity of the option is therefore beyond discussion.

Let me guess that another reason that this option is not yet implemented is
crisis of responsibility that the implementation will break something in
future.


> At one time in my lab it was very common to use -? (or more correctly
> -\?) to get help.  This was precisely because it is an invalid option
> for most programs and at the time most programs would dump a full help
> usage when parsing an invalid option.  And of course the MS-DOS
> command help option also was similar with /?.  From my experience I
> would say the number of people who try -? to return help exceeds those
> that try -h.
>

The subjective experience difference is exactly the reason I proposed a
poll.


> Not suggesting any implementation of this but just to show that
> culturally there are different expectations for help.  (The best one
> IMNHO being the actual option for help.)  Since any invalid option
> informs the caller about how to get the full help it isn't hard to
> find.
>

It is a constant annoyance, which doesn't present when you're dealing with
Python scripts. You wanted the -? for the reason, and now you alienate from
the idea by proposing that somebody else feels comfortable with working
this way. Citing the same Zen of Python "In the face of ambiguity, refuse
the temptation to guess."


> And personally I very much like the behavior that an invalid option
> just informs the user about how to get the longer full help usage.
>

That's a good ux case, but it is already working and done. We ux case we
are trying to solve is when user 100% knows that he needs a hint to call
this command, and the help should be accessible in the most convenient
(fastest) way possible. "-h" argument is the proposed variant that users
already know and use, so intuitive interface should implement their
expectation rather than trying to change them (thankfully there were no
such arguments here).

Very often I have simply made a small mistake that I recognize
> immediately.  If it were to emit the full long help then it would
> scroll of my my previous work off the top of the terminal.  That has
> been very annoying with commands that have that behavior.  I much
> prefer the current behavior.


You're expanding the original scenario. Nobody says that wrong option
should result in the list of help. Wrong option should show an error, so
we're not touching this.