From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: anatoly techtonik Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Sun, 17 Feb 2013 18:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 13737@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.136112751721388 (code B ref -1); Sun, 17 Feb 2013 18:59:02 +0000 Received: (at submit) by debbugs.gnu.org; 17 Feb 2013 18:58:37 +0000 Received: from localhost ([127.0.0.1]:33316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U79Rb-0005Yt-SZ for submit@debbugs.gnu.org; Sun, 17 Feb 2013 13:58:36 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49422) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U77XC-0002pB-NS for submit@debbugs.gnu.org; Sun, 17 Feb 2013 11:56:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U77WI-0005bU-W3 for submit@debbugs.gnu.org; Sun, 17 Feb 2013 11:55:19 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID,USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:42497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U77WI-0005bP-T9 for submit@debbugs.gnu.org; Sun, 17 Feb 2013 11:55:18 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U77WH-0003UD-7v for bug-coreutils@gnu.org; Sun, 17 Feb 2013 11:55:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U77WG-0005aV-CF for bug-coreutils@gnu.org; Sun, 17 Feb 2013 11:55:17 -0500 Received: from mail-la0-x233.google.com ([2a00:1450:4010:c03::233]:50363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U77WG-0005ZS-4W for bug-coreutils@gnu.org; Sun, 17 Feb 2013 11:55:16 -0500 Received: by mail-la0-f51.google.com with SMTP id fo13so4674785lab.24 for ; Sun, 17 Feb 2013 08:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=twqle2aILU3EjEsEJP/dEPjcxggwB5apsrusKNFlTh0=; b=J/nWum716y55TnQWlI0I6/Ol+ed/qTR/kXTvX2x0+zzcdgDBP9uF3p7D6ZUZalC2fY AXidsg2LDqDEU2QpNu/zCbf4IYLd1SVS8vftJd/156qtKE9lko1SDFyUlMrI/1XwD6jG EUFe7APeCfgoTGLPoEgvJDpkLuNJGNE4G1oCe5UB2a6LL/vfuBipTZdDDzyAGjntrRiV bTg9kuXXeFPcYSpQ2WECw+fd0nguE5mQylfgjoMbe+K6uinkCMhliucBByRaR5V7iHfN BppIE+hb0wbIXGR9ddMoRA82yizd6YLyK2mGeBvDM7UJ31/cSoyquD7HtWWh1dwQmMZW fVcw== X-Received: by 10.112.104.103 with SMTP id gd7mr4610556lbb.54.1361120112573; Sun, 17 Feb 2013 08:55:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.156.38 with HTTP; Sun, 17 Feb 2013 08:54:46 -0800 (PST) From: anatoly techtonik Date: Sun, 17 Feb 2013 19:54:46 +0300 Message-ID: Content-Type: multipart/alternative; boundary=14dae9d68298ce7f2204d5ee783a X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Mailman-Approved-At: Sun, 17 Feb 2013 13:58:33 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) --14dae9d68298ce7f2204d5ee783a Content-Type: text/plain; charset=UTF-8 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. --14dae9d68298ce7f2204d5ee783a Content-Type: text/html; charset=UTF-8
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.
--14dae9d68298ce7f2204d5ee783a-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Bob Proulx Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 05:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: anatoly techtonik Cc: 13737@debbugs.gnu.org Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136116642119258 (code B ref 13737); Mon, 18 Feb 2013 05:47:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 05:47:01 +0000 Received: from localhost ([127.0.0.1]:33707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7JZ7-00050Y-8O for submit@debbugs.gnu.org; Mon, 18 Feb 2013 00:47:01 -0500 Received: from joseki.proulx.com ([216.17.153.58]:33062) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7JZ4-00050L-DK for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 00:46:59 -0500 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id C021A211DA; Sun, 17 Feb 2013 22:45:59 -0700 (MST) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 7308C2DCDD; Sun, 17 Feb 2013 22:45:59 -0700 (MST) Date: Sun, 17 Feb 2013 22:45:59 -0700 From: Bob Proulx Message-ID: <20130218054559.GA10302@hysteria.proulx.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) 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 From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: anatoly techtonik Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 07:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: Bob Proulx Cc: 13737@debbugs.gnu.org Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136117278131915 (code B ref 13737); Mon, 18 Feb 2013 07:33:01 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 07:33:01 +0000 Received: from localhost ([127.0.0.1]:33763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7LDg-0008Ig-6z for submit@debbugs.gnu.org; Mon, 18 Feb 2013 02:33:00 -0500 Received: from mail-la0-f41.google.com ([209.85.215.41]:57465) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7LDc-0008IV-Mq for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 02:32:58 -0500 Received: by mail-la0-f41.google.com with SMTP id fo12so5195474lab.14 for <13737@debbugs.gnu.org>; Sun, 17 Feb 2013 23:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=SeqUaVeiRBJHYK9eHwm6gZAlqdrNg9vZthKY02veDy4=; b=whIxGvCtBDSCfZe8OHJuVj2JXIOApBjNOrWxADvCSXRd4t6rIgj3BmR3wJ0S/aOgV1 zhiVf5gG5m4lfgJasM8/f8vd0J2/0McSL///ysdr+iiwZntjkg/sWePePr12AAfUwF8t mtRWQZxEMikQvkXqIzJl+YiSzKIh/QF0y9vGZq2d/ihcfGhp5eo3ln3cLyGcdAm5v2vE YJfIo12w0F6ycBb7h6UcJTHso6aZ8sv3+hKfWZxYZXgtyNhQIyGTggiQN2+BZu31FRH7 ayysaRNaPRSe9lkFT+a1fHdED3282huQuB3u8286fBT8+lwsY+iEBeI8/dJ3r+tFUHyT Qh9g== X-Received: by 10.112.42.5 with SMTP id j5mr5160598lbl.37.1361172717278; Sun, 17 Feb 2013 23:31:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.156.38 with HTTP; Sun, 17 Feb 2013 23:31:36 -0800 (PST) In-Reply-To: <20130218054559.GA10302@hysteria.proulx.com> References: <20130218054559.GA10302@hysteria.proulx.com> From: anatoly techtonik Date: Mon, 18 Feb 2013 10:31:36 +0300 Message-ID: Content-Type: multipart/alternative; boundary=e0cb4efe35724a969c04d5fab8d2 X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) --e0cb4efe35724a969c04d5fab8d2 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 18, 2013 at 8:45 AM, Bob Proulx 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. =) --e0cb4efe35724a969c04d5fab8d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 18, 2013 at 8:45 AM, Bob Proulx <bob@proulx.com<= /a>> wrote:
severity 13737 wishlist
tag 13737 + wontfix
thanks

anatoly techtonik wrote:
> It is very inconvenient to type --help every time when you need to rea= d
> help. It will be useful to have -h shortcut (a de-facto standard in a<= br> > 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 do= n't understand your argument about "unique combination". The = main issue is that people like me expect -h to work as a --help shortcut. T= hey don't have a chance to know "--h" without reading the doc= s, so --h is not useful. And by the way - this --h is not documented.
=C2=A0
=C2=A0 $ 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.
=C2=A0
Also the users command doesn't have a complicated usage syntax.

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

But it gives something else, so to un= derstand what it actually does, I have to read the help. This is a complica= ted usage, because it is possible to have one step faster help access inste= ad of two step. This also have a complicated usage (not "usage syntax&= quot;), because it doesn't match to the users expectations towards shel= l command.

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

=C2=A0In
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. =3D)=C2=A0
--e0cb4efe35724a969c04d5fab8d2-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 17:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: anatoly techtonik Cc: 13737@debbugs.gnu.org, Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136120818131270 (code B ref 13737); Mon, 18 Feb 2013 17:23:01 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 17:23:01 +0000 Received: from localhost ([127.0.0.1]:34973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7UQe-00088J-M1 for submit@debbugs.gnu.org; Mon, 18 Feb 2013 12:23:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51930) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7UQb-000887-1g for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 12:22:59 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1IHLtuu020160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Feb 2013 12:21:55 -0500 Received: from [10.3.113.150] (ovpn-113-150.phx2.redhat.com [10.3.113.150]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1IHLsQV016108; Mon, 18 Feb 2013 12:21:54 -0500 Message-ID: <51226332.2090703@redhat.com> Date: Mon, 18 Feb 2013 10:21:54 -0700 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20130218054559.GA10302@hysteria.proulx.com> In-Reply-To: X-Enigmail-Version: 1.5.0 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2RPTLAJBPQGVNNQJWHXPW" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Spam-Score: -4.8 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RPTLAJBPQGVNNQJWHXPW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/18/2013 12:31 AM, anatoly techtonik wrote: > I don't understand your argument about "unique combination". The main i= ssue > 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 use= ful. > 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. >> >=20 > Sorry, but it is an argument. It will be interesting to know why though= =2E 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 expec= t -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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2RPTLAJBPQGVNNQJWHXPW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRImMyAAoJEKeha0olJ0NqTpEH/2WeFd/WHIfrg9/jxngjRTOQ a1HFQ6UrlEsKlCsEkc3USRMLfqkC1qkU7OiMabJQ2hpUF65lzTz1SjtwXQ6Ni6lV gUGtYWP3M8GeaBjAazUtir/aRmTvJn7y484EcE97fe860V+YsjPh6lSIYraf1ZOh RECHz8H8Bd/cxRdp2as3oJw+lqXYshDpbljdkQeF4mdIVFuXzWrKCSlnWPjBcWLH t0gFUkQg95KPGJpScvD9oLyzmhZeRdFGNTjuhVz+3HMwxCKpxw/wl6BOppeeqFGl lQvXUaL9HPL+gHKrMdS6LI/BxAZZpZgfodDkPTES4DbzJAvTkfhC8gaFzXOPOxo= =VAbr -----END PGP SIGNATURE----- ------enig2RPTLAJBPQGVNNQJWHXPW-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 18:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: Eric Blake Cc: 13737@debbugs.gnu.org, anatoly techtonik , Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.13612124718902 (code B ref 13737); Mon, 18 Feb 2013 18:35:01 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 18:34:31 +0000 Received: from localhost ([127.0.0.1]:35041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7VXr-0002JX-1v for submit@debbugs.gnu.org; Mon, 18 Feb 2013 13:34:31 -0500 Received: from mx.meyering.net ([88.168.87.75]:50508) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7VXn-0002JM-Ko for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 13:34:29 -0500 Received: from rho.meyering.net (rho.meyering.net [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 0F3D960096; Mon, 18 Feb 2013 19:33:24 +0100 (CET) From: Jim Meyering In-Reply-To: <51226332.2090703@redhat.com> (Eric Blake's message of "Mon, 18 Feb 2013 10:21:54 -0700") References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> Date: Mon, 18 Feb 2013 19:33:24 +0100 Message-ID: <87d2vxsc97.fsf@rho.meyering.net> Lines: 58 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) 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. From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Bob Proulx Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 20:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: 13737@debbugs.gnu.org, anatoly techtonik Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136121776620724 (code B ref 13737); Mon, 18 Feb 2013 20:03:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 20:02:46 +0000 Received: from localhost ([127.0.0.1]:35187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7WvG-0005OC-G6 for submit@debbugs.gnu.org; Mon, 18 Feb 2013 15:02:46 -0500 Received: from joseki.proulx.com ([216.17.153.58]:36210) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7WvD-0005O5-RZ for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 15:02:44 -0500 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id C37A4211D5; Mon, 18 Feb 2013 13:01:41 -0700 (MST) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 798582DCDD; Mon, 18 Feb 2013 13:01:41 -0700 (MST) Date: Mon, 18 Feb 2013 13:01:41 -0700 From: Bob Proulx Message-ID: <20130218200141.GA11045@hysteria.proulx.com> References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <87d2vxsc97.fsf@rho.meyering.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d2vxsc97.fsf@rho.meyering.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) 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 From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: anatoly techtonik Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 20:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: Eric Blake Cc: 13737@debbugs.gnu.org, Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136121956723290 (code B ref 13737); Mon, 18 Feb 2013 20:33:01 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 20:32:47 +0000 Received: from localhost ([127.0.0.1]:35215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7XOJ-00063b-4A for submit@debbugs.gnu.org; Mon, 18 Feb 2013 15:32:47 -0500 Received: from mail-la0-f51.google.com ([209.85.215.51]:49613) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7XOG-00063S-24 for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 15:32:45 -0500 Received: by mail-la0-f51.google.com with SMTP id fo13so5894180lab.10 for <13737@debbugs.gnu.org>; Mon, 18 Feb 2013 12:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OyoeIWuS4wmkjN9JI/tjyyr0U+LsU15IR4NQwHmlNMY=; b=OWzORJCs4WWoMoeFPFzStDjIDjU8C41LFLKD9LbG5hSwruwEJq2Ib3bjD0bofa5BCw +M50SlfMXeuXEhT9mITpg68FtfTRiz7vJAUyI+jvhDYpTBFJvMYarphw3ke6JNLu/hWn 7Luu7CFU1wFLU9LjaiAHrat6r4S6LUmTTGOuWFNTQZMMSfpiGK0zxh2FuqIot+cXpdrD MXzmN9PUVYUzuvvAT0adHbz+vXYKXZyQEG4sqjDFZGBXL4mf+p5IA7dGz3yaaziZZwks 1T4MVyii4oZ8bJJLP14mqUD1WKMfX4iwXWHkx8jHj22JXXfy/TGGxfPsHaeq2mr1R8jm lhJA== X-Received: by 10.112.103.196 with SMTP id fy4mr6153666lbb.125.1361219501596; Mon, 18 Feb 2013 12:31:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.156.38 with HTTP; Mon, 18 Feb 2013 12:31:21 -0800 (PST) In-Reply-To: <51226332.2090703@redhat.com> References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> From: anatoly techtonik Date: Mon, 18 Feb 2013 23:31:21 +0300 Message-ID: Content-Type: multipart/alternative; boundary=f46d0401f937daa20f04d6059c46 X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) --f46d0401f937daa20f04d6059c46 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 18, 2013 at 8:21 PM, 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. 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. --f46d0401f937daa20f04d6059c46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 02/18/2013 12:31 AM, anatoly techtoni= k wrote:
> I don't understand your argument about "unique combination&qu= ot;. The main issue
> is that people like me expect -h to work as a --help shortcut. They do= n'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. =C2=A0We 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?
=C2=A0
> 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 thoug= h.

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. =C2=A0Premature= ly
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.
<= br>
Do I understand it right that if OpenBSD implements &qu= ot;-h" - you'll copy?
And what if OpenBSD says tha= t "unless GNU implementation"?

I don't get why GNU development and usa= bility features should depend on non-GNU implementation?
Wh= at is the true reason?
=C2=A01. Liability dumping.
=C2=A02. No process to get statistical users preference.
= =C2=A03. Fear that '-h' option can be used for other purpose for &#= 39;users' in future.
=C2=A04. Attempt to solve specific= problem 'generic way'

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

Not generally. =C2=A0The GNU coding standards mandate '--help'= ;, they do NOT
mandate '-h'. =C2=A0More GNU users are used to '--help' tha= n they are for any
short option name.

What does '= ;mandate' mean?
Is there any 'common sense' exp= lanation for those standards?
In which year these 'mand= ations' 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. Th= at'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 du= bious.
=C2=A0
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 conser= vative hackers, who are pretty hard to reach and communicate over user expe= rience 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-advanc= ed Linux users, who often don't know how to use 'find' from the= command line.

"we have had a few" requests is a= lso not an argument on the web. Archives are searchable, so if you refuse t= o implement it this time - next time people will search, read you answer, a= nd decide to spend their time somewhere else.
--f46d0401f937daa20f04d6059c46-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 21:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: anatoly techtonik Cc: 13737@debbugs.gnu.org, Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136122114725511 (code B ref 13737); Mon, 18 Feb 2013 21:00:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 20:59:07 +0000 Received: from localhost ([127.0.0.1]:35229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Xnm-0006dP-O7 for submit@debbugs.gnu.org; Mon, 18 Feb 2013 15:59:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47410) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Xni-0006dE-Tt for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 15:59:05 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1IKw0xC018438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Feb 2013 15:58:00 -0500 Received: from [10.3.113.150] (ovpn-113-150.phx2.redhat.com [10.3.113.150]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1IKw0Ra016262; Mon, 18 Feb 2013 15:58:00 -0500 Message-ID: <512295D7.90709@redhat.com> Date: Mon, 18 Feb 2013 13:57:59 -0700 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> In-Reply-To: X-Enigmail-Version: 1.5.0 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2CWKWLNKFBUCNSVKHJSAX" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -5.6 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.5 (-------) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CWKWLNKFBUCNSVKHJSAX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > Is it a part of POSIX, RedHat or just usual man page for 'users'? Can y= ou > 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.ht= ml#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-optio= ns which is very near the beginning of 'info coreutils', our preferred documentation system. >=20 > 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. >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2CWKWLNKFBUCNSVKHJSAX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRIpXXAAoJEKeha0olJ0NqU4wH/0EJ5BemVN3sVo3JVhKUc1TL x1X1TixO/FZdQ6CqVUJ0w0yQ0lgY8V+efWm6cVEjr4+3tcynWj5ngXHZXRjVAZUw WPaSu026yzFosGqbEdgrXJKVXbIqArT0Ubu9m9UQ9PkevpRJu46+BkSf9640x72A TObBsr+gieyFX35gJWj+9Ps96yegcJRbJw4OcK/HXVFkMKatJmJmmPi+fkWX5vTq LKbD8IPpTtqfJ8xKFnPReL1REkKcr6Dqm29Lyp0/t9P2fGTL2JH7+MHUzy9+5HZQ uPS2FwoRu8k+1u6F6S45dyn8Wdem73nS3Gse73MnfZfxLf0/IUSeBVp9bi7ewTY= =lpWv -----END PGP SIGNATURE----- ------enig2CWKWLNKFBUCNSVKHJSAX-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: anatoly techtonik Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 21:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: Jim Meyering Cc: 13737@debbugs.gnu.org, Eric Blake , Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136122118025554 (code B ref 13737); Mon, 18 Feb 2013 21:00:03 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 20:59:40 +0000 Received: from localhost ([127.0.0.1]:35232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7XoJ-0006e7-4s for submit@debbugs.gnu.org; Mon, 18 Feb 2013 15:59:39 -0500 Received: from mail-la0-f43.google.com ([209.85.215.43]:58074) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7XoF-0006dy-W2 for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 15:59:37 -0500 Received: by mail-la0-f43.google.com with SMTP id ek20so5941249lab.16 for <13737@debbugs.gnu.org>; Mon, 18 Feb 2013 12:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=j2em3VAzhUa5xQ9hlfhnrQIJzHxbKY1s7/x3jVQ0NYk=; b=EUjb7kWs39iT9gZ/AgArIf/6vQzAkb3iIwJRHV6JaLXAI2HILKYWgulBLB5M0u2a3i HmxYdgwa9KZLm8u/geY7PeCCn/mUYDraEPBBe9arMxw5QMV6gvGeXGIC+zl73g7UlVnO tNbi3/74RjYHd3IoGQIwKkFS9P3GEPj8fJeiI08rvctjGzskQQQ9nz7NAejA1/Fv2evZ dTstYV50cqt+EoRUC3feKZGut8zAvAzRx1tkSfx3/oJRP6L2mPefy85OandWY1Calhut MRyJ1910Qthm7M1vfqSXv1RGH5NY9G5V1sPbV4iJYAyW9+7+FVwMwnzpolTp0iTLbjyp ODLQ== X-Received: by 10.112.87.105 with SMTP id w9mr6063563lbz.14.1361221113223; Mon, 18 Feb 2013 12:58:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.156.38 with HTTP; Mon, 18 Feb 2013 12:58:13 -0800 (PST) In-Reply-To: <87d2vxsc97.fsf@rho.meyering.net> References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <87d2vxsc97.fsf@rho.meyering.net> From: anatoly techtonik Date: Mon, 18 Feb 2013 23:58:13 +0300 Message-ID: Content-Type: multipart/alternative; boundary=bcaec554e106ea1ce004d605fc07 X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --bcaec554e106ea1ce004d605fc07 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 18, 2013 at 9:33 PM, Jim Meyering 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. --bcaec554e106ea1ce004d605fc07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 18, 2013 at 9:33 PM, Jim Meyering <jim@meyerin= g.net> wrote:
Eric Blake wrote:
> On 02/18/2013 12:31 AM, anatoly techtonik wrote:
>> I don't understand your argument about "unique combinatio= n". The main issue
>> is that people like me expect -h to work as a --help shortcut. The= y 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. =C2=A0We document that ALL long options can be<= br> > 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 t= hough.
>
> 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. =C2=A0Prem= aturely
> 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 us= ers expect -h
>> to work as --help by default.
>
> Not generally. =C2=A0The GNU coding standards mandate '--help'= , they do NOT
> mandate '-h'. =C2=A0More 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 reques= ts
> 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 p= rovided by adding '-h' for showing help to 80% commands that don= 9;t have this option outweights the _possible_ usability disadvantage of us= ing 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.
=C2=A0
This command shows the affected programs:

=C2=A0 =C2=A0 $ grep -le -h, *.c
=C2=A0 =C2=A0 chcon.c
=C2=A0 =C2=A0 chgrp.c
=C2=A0 =C2=A0 chown-core.c
=C2=A0 =C2=A0 chown.c
=C2=A0 =C2=A0 df.c
=C2=A0 =C2=A0 du.c
=C2=A0 =C2=A0 ls.c
=C2=A0 =C2=A0 nl.c
=C2=A0 =C2=A0 pr.c
=C2=A0 =C2=A0 sort.c
=C2=A0 =C2=A0 touch.c

~$ chcon -h<= /div>
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
=C2=A0 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 command= s inhibit the same behaviour:
chgrp
chown
nl
p= r
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.=C2=A0Users running these four comm= ands 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 comman= ds, but it is not the reason to prevent "-h" usability improvemen= t to other commands, including 'users'. If you're think it is t= he reason, please explain why in a way that new Linux users can get it.
=C2=A0
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 pur= ity.
...
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'r= e not convinced about and what are your concerns. It will help to keep this= focused. The original request was for the 'users' command.

--=C2=A0
anatoly t.
--bcaec554e106ea1ce004d605fc07-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 21:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: anatoly techtonik Cc: 13737@debbugs.gnu.org, Jim Meyering , Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136122200926812 (code B ref 13737); Mon, 18 Feb 2013 21:14:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 21:13:29 +0000 Received: from localhost ([127.0.0.1]:35250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Y1g-0006yP-W4 for submit@debbugs.gnu.org; Mon, 18 Feb 2013 16:13:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40766) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Y1d-0006yF-Kc for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 16:13:27 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1ILCMQL023556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Feb 2013 16:12:22 -0500 Received: from [10.3.113.150] (ovpn-113-150.phx2.redhat.com [10.3.113.150]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1ILCMf8006198; Mon, 18 Feb 2013 16:12:22 -0500 Message-ID: <51229935.7080600@redhat.com> Date: Mon, 18 Feb 2013 14:12:21 -0700 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <87d2vxsc97.fsf@rho.meyering.net> In-Reply-To: X-Enigmail-Version: 1.5.0 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2JFPIFIIEXCWISWDMQHPH" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Spam-Score: -7.5 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.5 (-------) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JFPIFIIEXCWISWDMQHPH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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.= >> >=20 > ~$ chcon -h > chcon: missing operand > Try `chcon --help' for more information. >=20 > 1st is not too serious - user didn't get the help - but the hint is the= re > 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 'us= ers' > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2JFPIFIIEXCWISWDMQHPH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRIpk1AAoJEKeha0olJ0Nqhm8H/iO1tjR+C6H8peQaopw7Jjbi 8OfpyTCz41x/qc0k7Rin+xoE7dNavHgZQ0XZfFyC87uIML6pwgt2T0G6yQzPTL4s j22DCt5MDRdpmKdQHtYnpoCNTN23xjIuEQ+IeKUO5N8DGgjHV/VO3tP5rF6lf0wN mrqe8hOri1isDkavTNfDIMdfA2DliQaGNYs8uSgPnFpzKDntl+0QANgFE84XuQND DHCkrcVT9cSdMkuk+0hxfvF1Ml7e9XCS44hB/AKhYPvGzI4PClOcfWb499jnbIgU 2yWNLA3ok2RloQW2OF238jUE6SNnf9t5VoypznrRu1FyF3bpkFJws7fUyJtOxUM= =1+g9 -----END PGP SIGNATURE----- ------enig2JFPIFIIEXCWISWDMQHPH-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: anatoly techtonik Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 21:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: Bob Proulx Cc: 13737@debbugs.gnu.org Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136122228430676 (code B ref 13737); Mon, 18 Feb 2013 21:19:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 21:18:04 +0000 Received: from localhost ([127.0.0.1]:35255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Y67-0007yj-NH for submit@debbugs.gnu.org; Mon, 18 Feb 2013 16:18:04 -0500 Received: from mail-la0-f46.google.com ([209.85.215.46]:64557) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Y63-0007yJ-Mu for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 16:18:01 -0500 Received: by mail-la0-f46.google.com with SMTP id fq12so5939156lab.19 for <13737@debbugs.gnu.org>; Mon, 18 Feb 2013 13:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=TzhlPYUFOZ28a/twa6SPwXVfj7o2mN3tN5Z+hrkVwDs=; b=BgpqzAW4XCQ41DhEWS1K7oI3OssoxmFRl8qPrgdAtmGZo4ib1eom8F0wosx0UbwSW9 DPiKtpWb2MOXkJuHzvcZiJBQxMncpsSxWZJqQO/7RrUrwF1yCaHZi/zMwOYljhNXAPU2 2xUOntSXOxlmnS6JDknvxPGRSOQcHYbGjsYkwHZDLzd4CdmGMHY5YutW58+g/yyD2vVk y55AVjoQc7chBNfU+vW/TMxJJhLwqhZAndplLMbzYhSkxxO1cAkm/eLjc8aLzO4hdBUm N1VCNKjrYq9C1wRkrfPV86KsMEDszFHF3vpbpUnzmQq1A9Boew6qTLmLlEoWNQdjT++o oyfw== X-Received: by 10.112.104.103 with SMTP id gd7mr6275232lbb.54.1361222217169; Mon, 18 Feb 2013 13:16:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.156.38 with HTTP; Mon, 18 Feb 2013 13:16:37 -0800 (PST) In-Reply-To: <20130218200141.GA11045@hysteria.proulx.com> References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <87d2vxsc97.fsf@rho.meyering.net> <20130218200141.GA11045@hysteria.proulx.com> From: anatoly techtonik Date: Tue, 19 Feb 2013 00:16:37 +0300 Message-ID: Content-Type: multipart/alternative; boundary=14dae9d68298b6fcc904d6063ed0 X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) --14dae9d68298b6fcc904d6063ed0 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 18, 2013 at 11:01 PM, Bob Proulx 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. --14dae9d68298b6fcc904d6063ed0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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. =C2=A0That is also an issue. =C2=A0Because -h is so often alread= y 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 thi= s 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 necess= ity 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 implemen= tation will break something in future.
=C2=A0
At one time in my lab it was very common to use -? (or more correctly
-\?) to get help. =C2=A0This was precisely because it is an invalid option<= br> for most programs and at the time most programs would dump a full help
usage when parsing an invalid option. =C2=A0And of course the MS-DOS
command help option also was similar with /?. =C2=A0From my experience I would say the number of people who try -? to return help exceeds those
that try -h.

The subjective exper= ience difference is exactly the reason I proposed a poll.
=C2=A0<= /div>
Not suggesting any implementation of this but just to show that
culturally there are different expectations for help. =C2=A0(The best one IMNHO being the actual option for help.) =C2=A0Since 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 propos= ing 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."
=C2=A0
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 alre= ady working and done. We ux case we are trying to solve is when user 100% k= nows that he needs a hint to call this command, and the help should be acce= ssible in the most convenient (fastest) way possible. "-h" argume= nt is the proposed variant that users already know and use, so intuitive in= terface should implement their expectation rather than trying to change the= m (thankfully there were no such arguments here).

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

You'= re expanding the original scenario. Nobody says that wrong option should re= sult in the list of help. Wrong option should show an error, so we're n= ot touching this.
--14dae9d68298b6fcc904d6063ed0-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: anatoly techtonik Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 21:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: Eric Blake Cc: 13737@debbugs.gnu.org, Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.1361223985798 (code B ref 13737); Mon, 18 Feb 2013 21:47:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 21:46:25 +0000 Received: from localhost ([127.0.0.1]:35260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7YXY-0000Cn-Ga for submit@debbugs.gnu.org; Mon, 18 Feb 2013 16:46:25 -0500 Received: from mail-la0-f43.google.com ([209.85.215.43]:64841) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7YXT-0000CY-Fx for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 16:46:21 -0500 Received: by mail-la0-f43.google.com with SMTP id ek20so5976593lab.16 for <13737@debbugs.gnu.org>; Mon, 18 Feb 2013 13:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NtnwpZXrD3r0d2Mzj/7LJztvCfXegDaN3ufCxoGgj/Y=; b=b5rzmp9DQaJsSB6+3W+dQzWmfEIwp3kQghCTlKEriMkWjG8XZ2sqnkVTDxCca5RLAC DbpMTTQu4m9scScgC/AtWFjhLl/TObhocztZvPj9pPJsl/otajbwuOd+Y19O6I64jTnN sqkahsmHtbaOXF7BmtFzCv1SLnwlnJq3lPRN579XBMFhDcrR15Bz9XQAEcrN3wU8s+9Y 60N4KYhSUUerk98Lm02x8Wzl4EbbpT2lNLTzVLBGrS+MGpYNXuuk4MTlv3aOEcFn3OAL /PdVsvDBMNN0pqGqf1ggmoaiJOY3bkIt17nF/S+aZ3s0PTXCcv1HlN7TW4jK/o8pr7A3 ovgg== X-Received: by 10.152.110.6 with SMTP id hw6mr12094811lab.43.1361223916296; Mon, 18 Feb 2013 13:45:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.156.38 with HTTP; Mon, 18 Feb 2013 13:44:56 -0800 (PST) In-Reply-To: <512295D7.90709@redhat.com> References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <512295D7.90709@redhat.com> From: anatoly techtonik Date: Tue, 19 Feb 2013 00:44:56 +0300 Message-ID: Content-Type: multipart/alternative; boundary=bcaec54b48d0fd9b8004d606a37d X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --bcaec54b48d0fd9b8004d606a37d Content-Type: text/plain; charset=UTF-8 On Mon, Feb 18, 2013 at 11:57 PM, Eric Blake 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. =) --bcaec54b48d0fd9b8004d606a37d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 18, 2013 at 11:57 PM, Eric Blake <eblake@redh= at.com> wrote:
On 02/18/2013 01:31 PM, anatoly techtoni= k wrote:
>> We HAVE documented it. =C2=A0We document that ALL long options can= be
>> represented by an unambiguous prefix, so --h is an unambiguous pre= fix 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= 9;? Can you
> post a proof link here?

Long options are not specified by POSIX. =C2=A0But they are commonly<= br> implemented by getopt_long(), which documents the GNU-standard behavior
of recognizing unambiguous prefix. =C2=A0The glibc manual doesn't docum= ent
prefix handling (arguably a bug in glibc documentation, but that is not
a question for this list):
https://www.gnu.org/soft= ware/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/manua= l/coreutils.html#Common-options

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

It is documente= d that "most programs recognize unambiguous abbreviations" of lon= g 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 r= eally a choice if you ask me. Python option parsing went long way getopt -&= gt; 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 tar= get documentation audience reads stackoverflow nowadays. Therefore, how man= y users are actually aware of "--h" option and intuitively use it= instead of "-h"? I can't answer this question without the po= ll, 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" - y= ou'll copy?

Yes, if there is existing practice of burning '-h' to mean he= lp 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. =C2=A0But w= e
aren't going to lead the pack on burning a short option for something like help.

And if I say that the whol= e cross-platform Python stack burned "-h, --help" as default opti= ons of providing help to console scripts? This goes way beyond OpenBSD and = even POSIX. Is that enough?
=C2=A0
> I don't get why GNU development and usability features should depe= nd on
> non-GNU implementation?

GNU prefers long options. =C2=A0We support short options insofar as s= tandards
documents and compatibility dictate, but don't let short options drive<= br> 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= . =3D)
--bcaec54b48d0fd9b8004d606a37d-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Bernhard Voelker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 21:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: anatoly techtonik Cc: 13737@debbugs.gnu.org, Eric Blake , Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.13612245171615 (code B ref 13737); Mon, 18 Feb 2013 21:56:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 21:55:17 +0000 Received: from localhost ([127.0.0.1]:35276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Yg9-0000Q0-Kq for submit@debbugs.gnu.org; Mon, 18 Feb 2013 16:55:17 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]:49930) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Yg7-0000Ps-8L for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 16:55:16 -0500 Received: from [192.168.1.11] (p5091F527.dip.t-dialin.net [80.145.245.39]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M40UE-1Uxjbn06Ve-00ra08; Mon, 18 Feb 2013 22:54:09 +0100 Message-ID: <5122A300.5040303@bernhard-voelker.de> Date: Mon, 18 Feb 2013 22:54:08 +0100 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:zbywxakA72NvzVr9QfdgM9W5t4hx4mUQ17CJDRbegxA s+WgY9fzzscBkbUt0wmhg0BU7FBtICudCeH3Gqg09+pOzdIBT6 Pu1dnYz0mHkuzImX2qj7dPV9gPoyxWVH9d4LKACLMHh4K4WTl9 ixcYpFVH9Ji0kcCciTcIzkvLG6NGtIvOprzQKoQslZtC/xu4HT pfTzAadnHKSzrW0OPnGAPVU3fMMVB3gIiCFcqqRbCp2QdUBU9P K772GFxJIjX27TZ8cRBKHHj9HOX4cHOV/jG+mLbyFDAIBlUlVT 9GNQaGQ8tk0RCrLqDAguUX8VIsz8I4cNlC5dyJfW10ppavy0Qd PAPtK2Eh4Jza9M/5uUFrANj7MU0keyzTDsbG8Bp7q X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) On 02/18/2013 09:31 PM, anatoly techtonik wrote: > On Mon, Feb 18, 2013 at 8:21 PM, Eric Blake 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 From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 22:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: Jim Meyering Cc: 13737@debbugs.gnu.org, anatoly techtonik , Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.13612259383622 (code B ref 13737); Mon, 18 Feb 2013 22:19:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 22:18:58 +0000 Received: from localhost ([127.0.0.1]:35285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Z33-0000wM-Jr for submit@debbugs.gnu.org; Mon, 18 Feb 2013 17:18:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52767) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Z30-0000wE-De for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 17:18:56 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1IMHpjG013875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Feb 2013 17:17:52 -0500 Received: from [10.3.113.150] (ovpn-113-150.phx2.redhat.com [10.3.113.150]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1IMHpJi013262; Mon, 18 Feb 2013 17:17:51 -0500 Message-ID: <5122A88F.8080106@redhat.com> Date: Mon, 18 Feb 2013 15:17:51 -0700 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <87d2vxsc97.fsf@rho.meyering.net> In-Reply-To: <87d2vxsc97.fsf@rho.meyering.net> X-Enigmail-Version: 1.5.0 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2PHRKDEIEDQIXRCJCJEAI" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -5.6 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.5 (-------) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PHRKDEIEDQIXRCJCJEAI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/18/2013 11:33 AM, Jim Meyering wrote: >=20 > 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). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2PHRKDEIEDQIXRCJCJEAI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRIqiPAAoJEKeha0olJ0Nq3vkIAKi6QyVzEjAj1liND4AbR84j r+FcKNVEWHd788xBgkSJJAmkinMNHDmSuRKcqUXKxHGIUQaxbsbIf32ae93kwaW9 J1oTtD4YdA/lPLxEqSV6i7Mcl3J7e95YvJnhRCzKWlf4acYY2Mv9BArAWrlmCMS/ MMXHjaCcH0uTtmq3FVonFUfFV83pCH1fYnY8CNX0IBQqyG0SvVoskjV5Y5TjHcKG gRnHMvCWHlo0txosFFlfXtJkqSckjD3BCmak5VsAsjaGSneKYKEHEOOw/QpPqOHR oQDlNX5E7r7tCQWxkrsMUGQcBPhdWQtgOkb8LaPobO8QngOBIHX/zkSKKzmscyE= =AVK+ -----END PGP SIGNATURE----- ------enig2PHRKDEIEDQIXRCJCJEAI-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: anatoly techtonik Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 18 Feb 2013 22:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: Eric Blake Cc: 13737@debbugs.gnu.org, Jim Meyering , Bob Proulx Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.13612260763835 (code B ref 13737); Mon, 18 Feb 2013 22:22:02 +0000 Received: (at 13737) by debbugs.gnu.org; 18 Feb 2013 22:21:16 +0000 Received: from localhost ([127.0.0.1]:35289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Z5F-0000zk-Ao for submit@debbugs.gnu.org; Mon, 18 Feb 2013 17:21:16 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:57471) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7Z5B-0000zb-72 for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 17:21:11 -0500 Received: by mail-lb0-f169.google.com with SMTP id m4so4666585lbo.14 for <13737@debbugs.gnu.org>; Mon, 18 Feb 2013 14:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Mjngf/O0CUcF39zrYE87VGpCJu/M7LN4QxvoYYeoCnw=; b=KE+h4kzEvlsLqka3iJJs/tFv/OcaDVeMVPg5KqNP7SU3GbUkAeGwejYGJMXBX+CQyc fF/vAQU9ykK4tcftxi5tEUFr3MUeVj9o8crtJPq9Olmuhd6gE6gmkAyf6ciki91PMcOq NUXnUF/B2t9EnShHFsVkvK7TxFSnjsA64rO0kvKpokUpR0lMKBYwuEHRlO0BPeQSE15B jSbCL9CnlWWIdhoaxD67X2fsFNBWMriR+Eg3RBDTSoWvfisfZ0zQKEPM3AN52w2tlEln 8+KuvGmr/PBi78a0LpLosrG5UU/n9AS2+6FqwmRebsCvYZc6NKRbCY8pT33Yre2K8h96 yyyg== X-Received: by 10.112.42.5 with SMTP id j5mr6184977lbl.37.1361226006276; Mon, 18 Feb 2013 14:20:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.156.38 with HTTP; Mon, 18 Feb 2013 14:19:46 -0800 (PST) In-Reply-To: <51229935.7080600@redhat.com> References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <87d2vxsc97.fsf@rho.meyering.net> <51229935.7080600@redhat.com> From: anatoly techtonik Date: Tue, 19 Feb 2013 01:19:46 +0300 Message-ID: Content-Type: multipart/alternative; boundary=e0cb4efe3572902bf204d6072032 X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e0cb4efe3572902bf204d6072032 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 19, 2013 at 12:12 AM, Eric Blake 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. --e0cb4efe3572902bf204d6072032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 19, 2013 at 12:12 AM, Eric Blake <eblake@redh= at.com> wrote:
On 02/18/2013 01:58 PM, anatoly techtoni= k wrote:

>> This command shows the affected programs:
>>
>> =C2=A0 =C2=A0 $ grep -le -h, *.c
>> =C2=A0 =C2=A0 chcon.c
>> =C2=A0 =C2=A0 chgrp.c
>> =C2=A0 =C2=A0 chown-core.c
>> =C2=A0 =C2=A0 chown.c
>> =C2=A0 =C2=A0 df.c
>> =C2=A0 =C2=A0 du.c
>> =C2=A0 =C2=A0 ls.c
>> =C2=A0 =C2=A0 nl.c
>> =C2=A0 =C2=A0 pr.c
>> =C2=A0 =C2=A0 sort.c
>> =C2=A0 =C2=A0 touch.c

And someday I want to add chmod to the list, as 'chmod -h' ac= ting 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?
=C2=A0
>>
>
> ~$ 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 i= s there
> =C2=A0 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. =C2=A0Instead, the use= r
should learn to use --help, which we CAN do globally. =C2=A0Supporting 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 belo= ng to coreutils. In these commands "-h" works ok, so it is imposs= ible to teach users anythings, but easy to make them suffer instead every t= ime 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= 9; command. Now you're saying that "-h" can not be added to &= #39;users' because 'chown' on BSD already has it. I am overreac= ting, but hopefully you see the problem.
=C2=A0
> It will help to keep this focused. The original request was for the &#= 39;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 t= o all
of coreutils.

Can you please explain = this 'prior art' argument? I suspect that you insist on solving thi= s '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-argum= ents. The argumentation "we've already decided" comes as a su= rprise - my thought was actually that I provided enough reasons to say the = points against are not valid without some research. Probably we need to mak= e a list of conflicting points and it will be better if you could make a su= mmary of that, because I am starting to get lost.
=C2=A0
And yes, there ARE cases where = POSIX has burned -h to
mean something; 'chown -h' was added in POSIX 2001 but did not exis= t in
POSIX 1992. =C2=A0Adding -h to mean help just for the sake of adding it is<= br> best done as an all-or-none addition across coreutils.
It is not for the sake of adding it. It is for making uni= x 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-non= e", because POSIX hackers already missed that use case for some comman= ds.
=C2=A0
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 implementati= on of 'coreutils' package? I doubt that it can happen if there are = only two known implementations of coreutils which try not to break each oth= er, unless they communicate rather freely.

If it is a matter of just system app preced= ent, then any system script written in Python + optparse will have "-h= " option provided by default http://docs.python.org/2/library/optparse#gene= rating-help I am not an expert in Linux system commands, but I guess Ub= untu has the biggest chance for having that.
--e0cb4efe3572902bf204d6072032-- From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 19 Feb 2013 01:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: anatoly techtonik Cc: 13737@debbugs.gnu.org Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.136123741620337 (code B ref 13737); Tue, 19 Feb 2013 01:31:02 +0000 Received: (at 13737) by debbugs.gnu.org; 19 Feb 2013 01:30:16 +0000 Received: from localhost ([127.0.0.1]:35475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7c2B-0005Hy-WE for submit@debbugs.gnu.org; Mon, 18 Feb 2013 20:30:16 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:58798) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7c29-0005Hq-Pw for 13737@debbugs.gnu.org; Mon, 18 Feb 2013 20:30:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E740E39E8108; Mon, 18 Feb 2013 17:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91o8O9ABaGjo; Mon, 18 Feb 2013 17:29:10 -0800 (PST) Received: from [192.168.1.9] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 8A07139E8105; Mon, 18 Feb 2013 17:29:10 -0800 (PST) Message-ID: <5122D566.6080607@cs.ucla.edu> Date: Mon, 18 Feb 2013 17:29:10 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <512295D7.90709@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) 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. From unknown Sun Jun 22 03:58:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13737: Add -h option to 'users' Resent-From: Assaf Gordon Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 19 Oct 2018 01:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13737 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: wontfix To: 13737@debbugs.gnu.org Received: via spool by 13737-submit@debbugs.gnu.org id=B13737.153991306011937 (code B ref 13737); Fri, 19 Oct 2018 01:38:01 +0000 Received: (at 13737) by debbugs.gnu.org; 19 Oct 2018 01:37:40 +0000 Received: from localhost ([127.0.0.1]:57939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDJjQ-00036O-As for submit@debbugs.gnu.org; Thu, 18 Oct 2018 21:37:40 -0400 Received: from mail-pg1-f179.google.com ([209.85.215.179]:45103) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDJjO-000362-BC; Thu, 18 Oct 2018 21:37:38 -0400 Received: by mail-pg1-f179.google.com with SMTP id s3-v6so1810612pga.12; Thu, 18 Oct 2018 18:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=WM7R8JstZIE125Vk4QQ0WwjCdvEclaDeKB9B9e0FvzE=; b=s1Bea/GYRzhoNztzEpqJKyzbbuINWEz0gglf8hoWaw8gVgYu6f5neGswFZZevEW2Pl A/vIrmWEH64xVarNeWvb4IR65Lz7mk7gILyhEJLkqUezpMUNYO4PxXosvgLlG7X1x/AQ mcKKQyc81teZzWpIaIHa4td81uUEGheOyMSnCGofzvltTr9ZmSEQ+WYNpG2gJTrm17/h ICsFnKXUTrgmYFMe4whogUmBnh6o/jfj6r9GriIcONPm88KqAAek645LlFVIKbHaoXVp mD2CIlgYEYeM0geXwfsIDx16lsJbf9hh3knfWeFPiNFl3YY4RQ5PahTYzOGeaPyjOhFW aRfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WM7R8JstZIE125Vk4QQ0WwjCdvEclaDeKB9B9e0FvzE=; b=sDArjQCjZ6ugkjpqxhasl20dj9mpfAQswpj2CFJIZ4mqAvZIW6XpP6He4dJb1m+prm VBN5a5BtVYzepZkLyR0hKD/gQ1I5m48d8sqmi4eQanzXUj7QfrxNPu34K2vDll2sOKtG Cv9oHoGcwtdlGNArEr/COLhb97FPl07cKRFwlMI/UJk6cDqu6k9/4voc9riQtaaeEdzv TEKgOqZM6mCPsF09YCUy3mr8ZX9goUaTUEdPnL3MfIsrU9g7Uw+r4ty/7gYtbLt/NMMD Z7zLTZMBM+F6POjJRxwDsKYt3goNEd6KRmMwEP1llrC6mo6TztyrtseiJ9+YGJA9aoWP B7Kw== X-Gm-Message-State: ABuFfogw9fdwunscvg+Pj8FlKi3NjBxsM19Gp1M1e/GjiybbEt0WjjC/ O28Mo+PJRMy8BLmA1AwagUWUjmgu698= X-Google-Smtp-Source: ACcGV62r63GofMZhoovFGL5h8GgrfT6LPWvKPqPp+0LJq6QUKnnU9jog9Nnl18VoraAuk1HxzOTEfw== X-Received: by 2002:a63:cc51:: with SMTP id q17-v6mr30313005pgi.291.1539913051857; Thu, 18 Oct 2018 18:37:31 -0700 (PDT) Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38]) by smtp.googlemail.com with ESMTPSA id 5-v6sm28684045pgt.83.2018.10.18.18.37.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 18:37:30 -0700 (PDT) References: <20130218054559.GA10302@hysteria.proulx.com> <51226332.2090703@redhat.com> <512295D7.90709@redhat.com> <5122D566.6080607@cs.ucla.edu> From: Assaf Gordon Message-ID: <6f965f72-b2a9-8550-599e-d0b3feaae824@gmail.com> Date: Thu, 18 Oct 2018 19:37:28 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5122D566.6080607@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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