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

Previous Next

Package: coreutils;

Reported by: anatoly techtonik <techtonik <at> gmail.com>

Date: Sun, 17 Feb 2013 18:59:02 UTC

Severity: wishlist

Tags: wontfix

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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: 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)]

This bug report was last modified 6 years and 219 days ago.

Previous Next


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