On Mon, Feb 18, 2013 at 11:01 PM, Bob Proulx <bob@proulx.com> 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.