bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: anatoly techtonik
Subject: bug#13737: Add -h option to 'users'
Date: Mon, 18 Feb 2013 23:31:21 +0300

On Mon, Feb 18, 2013 at 8:21 PM, Eric Blake <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]