GNU bug report logs - #13737
Add -h option to 'users'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13737 in the body.
You can then email your comments to 13737 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: anatoly techtonik <techtonik <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Add -h option to 'users'
Date: Sun, 17 Feb 2013 19:54:46 +0300

[Message part 1 (text/plain, inline)]

It is very inconvenient to type --help every time when you need to read
help. It will be useful to have -h shortcut (a de-facto standard in a
Python world and probably scripts in other languages).
-- 
anatoly t.

[Message part 2 (text/html, inline)]

Message #8 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: anatoly techtonik <techtonik <at> gmail.com>
Cc: 13737 <at> debbugs.gnu.org
Subject: Re: bug#13737: Add -h option to 'users'
Date: Sun, 17 Feb 2013 22:45:59 -0700

severity 13737 wishlist
tag 13737 + wontfix
thanks

anatoly techtonik wrote:
> It is very inconvenient to type --help every time when you need to read
> help. It will be useful to have -h shortcut (a de-facto standard in a
> Python world and probably scripts in other languages).

You can already use "--h" as a short abreviation for "--help" since
that is a unique combination.

  $ users --h

Give that a try and please report back your comments concerning it.

The bar for adding new short options to the utilities is very high.
Also the users command doesn't have a complicated usage syntax.  In
order to add -h it would need a pretty strong justification.
Therefore I have tagged this as a wishlist and wontfix as a default
answer unless there is an opposition champion.

Bob

Message #15 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: anatoly techtonik <techtonik <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 13737 <at> debbugs.gnu.org
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 10:31:36 +0300

[Message part 1 (text/plain, inline)]

On Mon, Feb 18, 2013 at 8:45 AM, Bob Proulx <bob <at> proulx.com> wrote:

> severity 13737 wishlist
> tag 13737 + wontfix
> thanks
>
> anatoly techtonik wrote:
> > It is very inconvenient to type --help every time when you need to read
> > help. It will be useful to have -h shortcut (a de-facto standard in a
> > Python world and probably scripts in other languages).
>
> You can already use "--h" as a short abreviation for "--help" since
> that is a unique combination.
>

I don't understand your argument about "unique combination". The main issue
is that people like me expect -h to work as a --help shortcut. They don't
have a chance to know "--h" without reading the docs, so --h is not useful.
And by the way - this --h is not documented.


>   $ users --h
>
> Give that a try and please report back your comments concerning it.


Above.

The bar for adding new short options to the utilities is very high.
>

Sorry, but it is an argument. It will be interesting to know why though.


> Also the users command doesn't have a complicated usage syntax.


Actually, it is. I expected it to give me this information:
cut -d: -f1,3 /etc/passwd | egrep ':[0-9]{4}$' | cut -d: -f1

But it gives something else, so to understand what it actually does, I have
to read the help. This is a complicated usage, because it is possible to
have one step faster help access instead of two step. This also have a
complicated usage (not "usage syntax"), because it doesn't match to the
users expectations towards shell command.

To confirm that argument we'd have to run the poll - if the users expect -h
to work as --help by default. Do you know where we can run it? Does Debian
provide any kind of voting system for users/contributors?

 In
> order to add -h it would need a pretty strong justification.
> Therefore I have tagged this as a wishlist and wontfix as a default
> answer unless there is an opposition champion.
>

I am here. =)

[Message part 2 (text/html, inline)]

Message #18 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: anatoly techtonik <techtonik <at> gmail.com>
Cc: 13737 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 10:21:54 -0700

[Message part 1 (text/plain, inline)]

On 02/18/2013 12:31 AM, anatoly techtonik wrote:
> I don't understand your argument about "unique combination". The main issue
> is that people like me expect -h to work as a --help shortcut. They don't
> have a chance to know "--h" without reading the docs, so --h is not useful.
> And by the way - this --h is not documented.

We HAVE documented it.  We document that ALL long options can be
represented by an unambiguous prefix, so --h is an unambiguous prefix of
--help if there are no other long options beginning with h.

> The bar for adding new short options to the utilities is very high.
>>
> 
> Sorry, but it is an argument. It will be interesting to know why though.

We are reluctant to burn a short option letter on any utility
standardized by POSIX unless there are other non-GNU implementations
that have also burned the same letter for the same purpose.  Prematurely
burning a short option hinders an effort to enhance the standard;
whereas existing practice is a strong argument for implementing
something to make it easier to use GNU as a drop-in replacement that
gives the user freedom over the existing implementation.

> To confirm that argument we'd have to run the poll - if the users expect -h
> to work as --help by default.

Not generally.  The GNU coding standards mandate '--help', they do NOT
mandate '-h'.  More GNU users are used to '--help' than they are for any
short option name.

I am against adding -h as a short option without a lot more
justification than just a single user, since we have had so few requests
for a short option -h over the years.

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

[signature.asc (application/pgp-signature, attachment)]

Message #21 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 13737 <at> debbugs.gnu.org, anatoly techtonik <techtonik <at> gmail.com>,
	Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 19:33:24 +0100

Eric Blake wrote:
> On 02/18/2013 12:31 AM, anatoly techtonik wrote:
>> I don't understand your argument about "unique combination". The main issue
>> is that people like me expect -h to work as a --help shortcut. They don't
>> have a chance to know "--h" without reading the docs, so --h is not useful.
>> And by the way - this --h is not documented.
>
> We HAVE documented it.  We document that ALL long options can be
> represented by an unambiguous prefix, so --h is an unambiguous prefix of
> --help if there are no other long options beginning with h.
>
>> The bar for adding new short options to the utilities is very high.
>>>
>>
>> Sorry, but it is an argument. It will be interesting to know why though.
>
> We are reluctant to burn a short option letter on any utility
> standardized by POSIX unless there are other non-GNU implementations
> that have also burned the same letter for the same purpose.  Prematurely
> burning a short option hinders an effort to enhance the standard;
> whereas existing practice is a strong argument for implementing
> something to make it easier to use GNU as a drop-in replacement that
> gives the user freedom over the existing implementation.
>
>> To confirm that argument we'd have to run the poll - if the users expect -h
>> to work as --help by default.
>
> Not generally.  The GNU coding standards mandate '--help', they do NOT
> mandate '-h'.  More GNU users are used to '--help' than they are for any
> short option name.
>
> I am against adding -h as a short option without a lot more
> justification than just a single user, since we have had so few requests
> for a short option -h over the years.

Thanks for replying, Eric and Bob.
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.

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

Thus, we cannot do it across the board, and
that was another reason not to do it.

Message #24 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 13737 <at> debbugs.gnu.org, anatoly techtonik <techtonik <at> gmail.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 13:01:41 -0700

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.

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.

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.

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.
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.

Bob

Message #27 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: anatoly techtonik <techtonik <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 13737 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 23:31:21 +0300

[Message part 1 (text/plain, inline)]

On Mon, Feb 18, 2013 at 8:21 PM, Eric Blake <eblake <at> redhat.com> wrote:

> On 02/18/2013 12:31 AM, anatoly techtonik wrote:
> > I don't understand your argument about "unique combination". The main
> issue
> > is that people like me expect -h to work as a --help shortcut. They don't
> > have a chance to know "--h" without reading the docs, so --h is not
> useful.
> > And by the way - this --h is not documented.
>
> We HAVE documented it.  We document that ALL long options can be
> represented by an unambiguous prefix, so --h is an unambiguous prefix of
> --help if there are no other long options beginning with h.


Is it a part of POSIX, RedHat or just usual man page for 'users'? Can you
post a proof link here?


> > The bar for adding new short options to the utilities is very high.
> >>
> >
> > Sorry, but it is an argument. It will be interesting to know why though.
>
> We are reluctant to burn a short option letter on any utility
> standardized by POSIX unless there are other non-GNU implementations
> that have also burned the same letter for the same purpose.  Prematurely
> burning a short option hinders an effort to enhance the standard;
> whereas existing practice is a strong argument for implementing
> something to make it easier to use GNU as a drop-in replacement that
> gives the user freedom over the existing implementation.


Do I understand it right that if OpenBSD implements "-h" - you'll copy?
And what if OpenBSD says that "unless GNU implementation"?

I don't get why GNU development and usability features should depend on
non-GNU implementation?
What is the true reason?
 1. Liability dumping.
 2. No process to get statistical users preference.
 3. Fear that '-h' option can be used for other purpose for 'users' in
future.
 4. Attempt to solve specific problem 'generic way'

> To confirm that argument we'd have to run the poll - if the users expect
> -h
> > to work as --help by default.
>
> Not generally.  The GNU coding standards mandate '--help', they do NOT
> mandate '-h'.  More GNU users are used to '--help' than they are for any
> short option name.
>

What does 'mandate' mean?
Is there any 'common sense' explanation for those standards?
In which year these 'mandations' were invented?

Your phrase about GNU users preference can not be backed up by any proof
links, so it can not serve as an argument. That's why I proposed a poll.
Nowadays GNU users are also Python and Ruby users, where they used to '-h'
option, so your position is very dubious.


> I am against adding -h as a short option without a lot more
> justification than just a single user, since we have had so few requests
> for a short option -h over the years.


There is a strong stereotype that core unix developers is a cast of
conservative hackers, who are pretty hard to reach and communicate over
user experience issues, so I suspect people don't even try. I am not
speaking of you though. It is just an opinion I've heard from ordinary,
not-advanced Linux users, who often don't know how to use 'find' from the
command line.

"we have had a few" requests is also not an argument on the web. Archives
are searchable, so if you refuse to implement it this time - next time
people will search, read you answer, and decide to spend their time
somewhere else.

[Message part 2 (text/html, inline)]

Message #30 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: anatoly techtonik <techtonik <at> gmail.com>
Cc: 13737 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 13:57:59 -0700

[Message part 1 (text/plain, inline)]

On 02/18/2013 01:31 PM, anatoly techtonik wrote:
>> We HAVE documented it.  We document that ALL long options can be
>> represented by an unambiguous prefix, so --h is an unambiguous prefix of
>> --help if there are no other long options beginning with h.
> 
> Is it a part of POSIX, RedHat or just usual man page for 'users'? Can you
> post a proof link here?

Long options are not specified by POSIX.  But they are commonly
implemented by getopt_long(), which documents the GNU-standard behavior
of recognizing unambiguous prefix.  The glibc manual doesn't document
prefix handling (arguably a bug in glibc documentation, but that is not
a question for this list):
https://www.gnu.org/software/libc/manual/html_node/Getopt-Long-Options.html#Getopt-Long-Options

but the Linux man pages DO document abbreviations:
http://linux.die.net/man/3/getopt_long
"Long option names may be abbreviated if the abbreviation is unique or
is an exact match for some defined option."

Coreutils also documents it here:
https://www.gnu.org/software/coreutils/manual/coreutils.html#Common-options

which is very near the beginning of 'info coreutils', our preferred
documentation system.

> 
> Do I understand it right that if OpenBSD implements "-h" - you'll copy?

Yes, if there is existing practice of burning '-h' to mean help in some
other implementation, then the option cannot be standardized by POSIX to
mean anything else, so we might as well also make it mean help.  But we
aren't going to lead the pack on burning a short option for something
like help.

> And what if OpenBSD says that "unless GNU implementation"?

Good for them.  Burning short option letters is not something you want
to do lightly.

> 
> I don't get why GNU development and usability features should depend on
> non-GNU implementation?

GNU prefers long options.  We support short options insofar as standards
documents and compatibility dictate, but don't let short options drive
development.

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

[signature.asc (application/pgp-signature, attachment)]

Message #33 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: anatoly techtonik <techtonik <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 13737 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
	Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 23:58:13 +0300

[Message part 1 (text/plain, inline)]

On Mon, Feb 18, 2013 at 9:33 PM, Jim Meyering <jim <at> meyering.net> wrote:

> Eric Blake wrote:
> > On 02/18/2013 12:31 AM, anatoly techtonik wrote:
> >> I don't understand your argument about "unique combination". The main
> issue
> >> is that people like me expect -h to work as a --help shortcut. They
> don't
> >> have a chance to know "--h" without reading the docs, so --h is not
> useful.
> >> And by the way - this --h is not documented.
> >
> > We HAVE documented it.  We document that ALL long options can be
> > represented by an unambiguous prefix, so --h is an unambiguous prefix of
> > --help if there are no other long options beginning with h.
> >
> >> The bar for adding new short options to the utilities is very high.
> >>>
> >>
> >> Sorry, but it is an argument. It will be interesting to know why though.
> >
> > We are reluctant to burn a short option letter on any utility
> > standardized by POSIX unless there are other non-GNU implementations
> > that have also burned the same letter for the same purpose.  Prematurely
> > burning a short option hinders an effort to enhance the standard;
> > whereas existing practice is a strong argument for implementing
> > something to make it easier to use GNU as a drop-in replacement that
> > gives the user freedom over the existing implementation.
> >
> >> To confirm that argument we'd have to run the poll - if the users
> expect -h
> >> to work as --help by default.
> >
> > Not generally.  The GNU coding standards mandate '--help', they do NOT
> > mandate '-h'.  More GNU users are used to '--help' than they are for any
> > short option name.
> >
> > I am against adding -h as a short option without a lot more
> > justification than just a single user, since we have had so few requests
> > for a short option -h over the years.
>
> Thanks for replying, Eric and Bob.
> 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.
>

And that's ok. You can not be good for everyone. The usability advantage
provided by adding '-h' for showing help to 80% commands that don't have
this option outweights the _possible_ usability disadvantage of using this
option with commands that already support it for other purpose.

The usability disadvantage in this specific case is:
1. the confusion that user did't get the help
2. some state changing behavior

Let's study these specific cases.


> 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
>

~$ 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 following commands inhibit the same behaviour:
chgrp
chown
nl
pr
touch


Only these four commands actually do something when supplied with -h option:
df
du
ls
sort

The consequences of their execution with "-h" option are not
critical. Users running these four commands are able to figure out that
"-h" didn't work as intended and can resort to other familiar, but more
complex way of getting help. We can not change the meaning of "-h" options
for these four commands, but it is not the reason to prevent "-h" usability
improvement to other commands, including 'users'. If you're think it is the
reason, please explain why in a way that new Linux users can get it.


> Thus, we cannot do it across the board, and
> that was another reason not to do it.
>

Following Zen of Python as a good engineering practice:
...
Special cases aren't special enough to break the rules.
Although practicality beats purity.
...

I think it is exactly the case here. As you're saying it is "another
reason" - it will be good if you can summarize the reasons so far, tell if
there is something you're not convinced about and what are your concerns.
It will help to keep this focused. The original request was for the 'users'
command.

-- 
anatoly t.

[Message part 2 (text/html, inline)]

Message #36 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: anatoly techtonik <techtonik <at> gmail.com>
Cc: 13737 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>,
	Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 14:12:21 -0700

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Message #39 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: anatoly techtonik <techtonik <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 13737 <at> debbugs.gnu.org
Subject: Re: bug#13737: Add -h option to 'users'
Date: Tue, 19 Feb 2013 00:16:37 +0300

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #42 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: anatoly techtonik <techtonik <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 13737 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Tue, 19 Feb 2013 00:44:56 +0300

[Message part 1 (text/plain, inline)]

On Mon, Feb 18, 2013 at 11:57 PM, Eric Blake <eblake <at> redhat.com> wrote:

> On 02/18/2013 01:31 PM, anatoly techtonik wrote:
> >> We HAVE documented it.  We document that ALL long options can be
> >> represented by an unambiguous prefix, so --h is an unambiguous prefix of
> >> --help if there are no other long options beginning with h.
> >
> > Is it a part of POSIX, RedHat or just usual man page for 'users'? Can you
> > post a proof link here?
>
> Long options are not specified by POSIX.  But they are commonly
> implemented by getopt_long(), which documents the GNU-standard behavior
> of recognizing unambiguous prefix.  The glibc manual doesn't document
> prefix handling (arguably a bug in glibc documentation, but that is not
> a question for this list):
>
> https://www.gnu.org/software/libc/manual/html_node/Getopt-Long-Options.html#Getopt-Long-Options
>
> but the Linux man pages DO document abbreviations:
> http://linux.die.net/man/3/getopt_long
> "Long option names may be abbreviated if the abbreviation is unique or
> is an exact match for some defined option."
>
> Coreutils also documents it here:
> https://www.gnu.org/software/coreutils/manual/coreutils.html#Common-options
>
> which is very near the beginning of 'info coreutils', our preferred
> documentation system.


It is documented that "most programs recognize unambiguous abbreviations"
of long options, but these are not POSIX standards, not a recommendation
either - just a feature of getopt parser. To me it looks like the usability
choice is affected by the internal implementation of option parsing
library, not really a choice if you ask me. Python option parsing went long
way getopt -> optparse -> argparse -> docopt since the time getopt was
invented, and the "-h" option is the current best practice.

And I really doubt that much users nowadays have a chance to run over this
chapter in coreutils manual. 95% of the target documentation audience reads
stackoverflow nowadays. Therefore, how many users are actually aware of
"--h" option and intuitively use it instead of "-h"? I can't answer this
question without the poll, but I can suspect that "--h" doesn't work in
majority of unix commands provided by scripts.

>
> > Do I understand it right that if OpenBSD implements "-h" - you'll copy?
>
> Yes, if there is existing practice of burning '-h' to mean help in some
> other implementation, then the option cannot be standardized by POSIX to
> mean anything else, so we might as well also make it mean help.  But we
> aren't going to lead the pack on burning a short option for something
> like help.


And if I say that the whole cross-platform Python stack burned "-h, --help"
as default options of providing help to console scripts? This goes way
beyond OpenBSD and even POSIX. Is that enough?


> > I don't get why GNU development and usability features should depend on
> > non-GNU implementation?
>
> GNU prefers long options.  We support short options insofar as standards
> documents and compatibility dictate, but don't let short options drive
> development.


That's a good policy. "-h" is already a well matured practice to be
implemented, and I doesn't see any dictatorship documents that directly
stand against it. =)

[Message part 2 (text/html, inline)]

Message #45 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: anatoly techtonik <techtonik <at> gmail.com>
Cc: 13737 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
	Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 22:54:08 +0100

On 02/18/2013 09:31 PM, anatoly techtonik wrote:
> On Mon, Feb 18, 2013 at 8:21 PM, Eric Blake <eblake <at> redhat.com> wrote:
> Your phrase about GNU users preference can not be backed up by any proof
> links, so it can not serve as an argument. That's why I proposed a poll.
> Nowadays GNU users are also Python and Ruby users, where they used to '-h'
> option, so your position is very dubious.
> 
> 
>> I am against adding -h as a short option without a lot more
>> justification than just a single user, since we have had so few requests
>> for a short option -h over the years.

Maybe that's exactly the difference to Ruby et al: the GNU tools exist
much longer and have for sure learned their lessons of burning short
options. ;-)

BTW: the user is not lost with today's implementation:

  $ users -h
  users: invalid option -- 'h'
  Try 'users --help' for more information.

The step to the get help isn't too hard with that information, is it?

Have a nice day,
Berny

Message #48 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 13737 <at> debbugs.gnu.org, anatoly techtonik <techtonik <at> gmail.com>,
	Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 15:17:51 -0700

[Message part 1 (text/plain, inline)]

On 02/18/2013 11:33 AM, Jim Meyering wrote:

> 
> Thanks for replying, Eric and Bob.
> 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.

We COULD add -? as an alias for --help across the board; except that I'm
not a fan of using shell metacharacters which require quoting to avoid
unintentional globbing matches (nothing worse than having behavior
change based on the contents of the current working directory).

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

[signature.asc (application/pgp-signature, attachment)]

Message #51 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: anatoly techtonik <techtonik <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 13737 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>,
	Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#13737: Add -h option to 'users'
Date: Tue, 19 Feb 2013 01:19:46 +0300

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #54 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: anatoly techtonik <techtonik <at> gmail.com>
Cc: 13737 <at> debbugs.gnu.org
Subject: Re: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 17:29:10 -0800

On 02/18/2013 01:44 PM, anatoly techtonik wrote:
> "-h" is already a well matured practice to be
> implemented

'-h' means something other than "help" for 
many common GNU commands: ls, touch, sort, bash, etc.
If we got people into the habit
of thinking '-h' means help, they'll get confused
when "ls -h" doesn't do what they expect.  It may
be better to leave sleeping dogs lie.

Message #57 received at 13737 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 13737 <at> debbugs.gnu.org
Subject: Re: bug#13737: Add -h option to 'users'
Date: Thu, 18 Oct 2018 19:37:28 -0600

close 13737
stop

(triaging old bugs)

On 18/02/13 06:29 PM, Paul Eggert wrote:
> On 02/18/2013 01:44 PM, anatoly techtonik wrote:
>> "-h" is already a well matured practice to be
>> implemented
> 
> '-h' means something other than "help" for
> many common GNU commands: ls, touch, sort, bash, etc.
> If we got people into the habit
> of thinking '-h' means help, they'll get confused
> when "ls -h" doesn't do what they expect.  It may
> be better to leave sleeping dogs lie.

With no further comments in 5 years, I'm closing this request.

regards,
 - assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.