From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id +DVMNe8Eu17rVQAA0tVLHw (envelope-from ) for ; Tue, 12 May 2020 20:19:59 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id CA63FP4Eu17IFgAA1q6Kng (envelope-from ) for ; Tue, 12 May 2020 20:20:14 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A7B54940DB8 for ; Tue, 12 May 2020 20:20:11 +0000 (UTC) Received: from localhost ([::1]:55298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYbNr-0005Mo-7t for larch@yhetil.org; Tue, 12 May 2020 16:20:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53204) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYbNi-0005LE-A9 for bug-guix@gnu.org; Tue, 12 May 2020 16:20:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45026) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jYbNi-0004Mt-0Z for bug-guix@gnu.org; Tue, 12 May 2020 16:20:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jYbNh-0006UE-Rz for bug-guix@gnu.org; Tue, 12 May 2020 16:20:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#40549: More usability issues: Resent-From: Tom Zander Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 12 May 2020 20:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40549 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: zimoun Cc: 40549@debbugs.gnu.org Received: via spool by 40549-submit@debbugs.gnu.org id=B40549.158931477424893 (code B ref 40549); Tue, 12 May 2020 20:20:01 +0000 Received: (at 40549) by debbugs.gnu.org; 12 May 2020 20:19:34 +0000 Received: from localhost ([127.0.0.1]:56572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYbNF-0006TP-QU for submit@debbugs.gnu.org; Tue, 12 May 2020 16:19:34 -0400 Received: from mx.kolabnow.com ([95.128.36.41]:40038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYbND-0006TB-Mh for 40549@debbugs.gnu.org; Tue, 12 May 2020 16:19:32 -0400 Received: from localhost (unknown [127.0.0.1]) by ext-mx-out001.mykolab.com (Postfix) with ESMTP id 4CC95AEE; Tue, 12 May 2020 22:19:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freedommail.ch; h=content-type:content-type:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:date :subject:subject:from:from:received:received:received; s= dkim20160331; t=1589314764; x=1591129165; bh=VtLsPWcOvp+kKbXyf6T 91E7jjkcBwu52o8xNYVtkulM=; b=cHfmZ6lFEDXNt5/TW2bNVpAFPdInt51zYpX NJeu5stSQbQl17fBu7d/DUP9JYwk/XSplC25mNuexKb1m23ZAx6lEAUjAekf/rgK 56S2r/Q9AmYzwY5a4of13ilrZSoNu6M20fiMf1OvUa/AeawUXlD1EfxKouhpgv7G b5jWwyHi2Z+5Pe5Z1JhzG7MUHpJ+AxtdbCUhMCFDHY1mLRgZVZQAvDBqz+S6WLTq 7Q3kfD72mvmnTmw/HjkG/XDSpFeRYTCA9LBuOjlBpIgThUiJznZE4jHkXuUHSJQ6 UjRXTQZrLxe10F7V6+MKTHQ1qi5tQIDMiJu8Jm3pnCZf8/62ACjVsyJvi/QOtaJp /iauqk6MCqdjLFyc4nUXkBlxl44wLDnqrCn+KbDlSkfbK3nyxqbTspI5hHy9ZiI4 n8b0IXH3/zNiGtC7+SlUWwjR3WTCtrYpzuQpcHy4w5kzxPsr8b9lhaP/MTAqaCdN QsMEhrj4oNe7LMZwSzvbXANuvbm5yyuYh3pdg12M50GFQaG6l6J4aqplH2jwM3xe imKm0jcSsKkQLMU0112xPfqjs0j/oBAZP81QBsfI/SemCX2571nIC384uFx7EYEJ HhyO4QuWX3Pzk47jZHoMmOeMNxijJRLP5AkwSMq6S8u0BO1pZz4c4FA94vPZIDjB HtPK+V5c= X-Virus-Scanned: amavisd-new at mykolab.com X-Spam-Score: -1.9 Received: from mx.kolabnow.com ([127.0.0.1]) by localhost (ext-mx-out001.mykolab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRDvjQnHnPzf; Tue, 12 May 2020 22:19:24 +0200 (CEST) Received: from int-mx002.mykolab.com (unknown [10.9.13.2]) by ext-mx-out001.mykolab.com (Postfix) with ESMTPS id 545A212F; Tue, 12 May 2020 22:19:24 +0200 (CEST) Received: from ext-subm003.mykolab.com (unknown [10.9.6.3]) by int-mx002.mykolab.com (Postfix) with ESMTPS id F33D4380B; Tue, 12 May 2020 22:19:23 +0200 (CEST) Date: Tue, 12 May 2020 22:19:22 +0200 Message-ID: <5565734.MhkbZ0Pkbq@cherry> In-Reply-To: References: <6171889.DvuYhMxLoT@cherry> <1804825.CQOukoFCf9@cherry> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" Reply-to: Tom Zander From: Tom Zander via Bug reports for GNU Guix X-Scanner: scn0 X-Spam-Score: 0.49 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=freedommail.ch header.s=dkim20160331 header.b=cHfmZ6lF; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Scan-Result: default: False [0.49 / 13.00]; HAS_REPLYTO(0.00)[tomz@freedommail.ch]; GENERIC_REPUTATION(0.00)[-0.53974258342901]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.06), country: US(-0.00), ip: 209.51.188.17(-0.54)]; DWL_DNSWL_FAIL(0.00)[209.51.188.17:server fail]; R_DKIM_REJECT(1.00)[freedommail.ch:s=dkim20160331]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[freedommail.ch:-]; MAILLIST(-0.20)[mailman]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; TAGGED_FROM(0.00)[larch=yhetil.org]; FROM_NEQ_ENVFROM(0.00)[bug-guix@gnu.org,bug-guix-bounces@gnu.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gnu.org]; MIME_GOOD(-0.10)[text/plain]; HAS_LIST_UNSUB(-0.01)[]; DNSWL_BLOCKED(0.00)[209.51.188.17:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.51.188.17:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_SEVEN(0.00)[11]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: 2+yxaoo8ZHCk On dinsdag 12 mei 2020 20:08:32 CEST zimoun wrote: > > The design of the short options is that it is an alias. Identical to the > > software regardless of what the user typed. >=20 > Yes. But AFAIU, it is hard -- not impossible -- to detect what is an > argument or what is another option in the case of optional argument in > the short-name form. Because it leads to ambiguous parsing. The solution here is to be consistent with the way that others do this. =46or those cases that you highlight the consistent solution elsewhere is=20 something you can apply here too. This follows the rule of the least surpri= se. =20 > And try "cut -f -d' '", it raises the error "cut: invalid field value =E2= =80=98d =E2=80=99". that is because -f has a required argument. As such I agree with your examp= le,=20 but ignore it because it is not relevant to our discussion. It is not an=20 optional short option. =20 > All short-name and long-name are ``equivalent`` when they do not > require any argument -- for example with cut: -s, --only-delimited -- > *_or_* they require one argument -- for example: -f, --fields=3DLIST. They are expected to always be equivalent. It would not be logical to have = the=20 short one as an alias if they are not equivalent. > But there is an ambiguity for optional argument. How do you detect if > the argument is provided or not? > With the long-name, it is done with the character '=3D'. > For short-name, it is ambiguous. Imagine that "guix package" has in The point here is that there exist rules that others use, to remove this=20 ambiguity. I'm trying to explain them to you to allow guix to behave the sa= me. I agree its tricky, the good thing is that it has been solved before. =46or instance you can provide an argument to short options without spaces = too: You can write `cut -f1 -d:`. > addition to '-S' the option '-2' meaning verbosity to level 2 > (--verbosity=3D2). Then what is the meaning of: >=20 > guix package -S -2 If the user meant the "-2" argument to be an argument to the -S option, the= y=20 would have to write (again, following the rules used by most software) as: echo "test" > -bla ls -I \-bla or, to comment on your specific example. In git you don't use the dash to h= ave=20 a negative, they use a different char. The tilde. Or dotdotdot. (think: ran= ge) git show HEAD~ git diff ...master > Is it equivalent to > + --switch-generation=3D-2 > or > + --switch-generation --verbose=3D2 In most software you would interpret any argument that starts with a dash a= s=20 an option. For consistency sake you would thus interpret your example as th= e=20 latter option. The user can specify what they mean, but preferably you pick your syntax=20 better to avoid the -2 in the example you gave :) > > You asked for an example; see `git commit -S`. From the manpage: > > -S[], --gpg-sign[=3D] >=20 > Thank you for the example. Let me show you that it raises an issue > too because it is not so "simple". :-) Easier example then: from the 'ls(1)' manpage: -I, --ignore=3DPATTERN seems git is trying to be smart. =20 > > It looks like the parser could be improved by preferring to see any > > argument with leading dash as a option when it **might** be an argument. >=20 > It does not work for the general case as you describe. It is not so simp= le. > :-) Because '-d -1' means '--delete-generation=3D-1' and not > '--delete-generation -1'. The point is consistency. The point is not to reinvent the wheel that have been invented so many=20 times... A command line parser is a known thing that you can, and should,=20 mirror how others do things. So, sure, "-d -1" does not give you what you want. BUT it is consistent with =2D-delete -1. This is the point the exercise. The basic premise is that the short version= is=20 an alias for the long version. Yes, you have to be aware of how to format things, how the rules apply. But= =20 this is the entire point: people should be able to learn it once. And not=20 again for guix because we thought something else worked better... > From my knowledge, all that is solved by the rule: no short option > with optional argument. Sure, you can do that. You'll probably annoy of a lot of people if you remove the thing they=20 use a lot :) Even 'ls' uses optional short arguments (--ignore). So I'm not sure I agree= =20 with your line of reasoning. > > So; if you type -`guix package -l --help` then your parser **first** fi= nds > > all the items with leading dashes and second it tries to find out if > > there is an argument for the `-l`. > > In this case I expect the help to be shown. > >=20 > > This is widely seen as a solution. > > Users can still use items with leading dashes by using two commonly used > > tricks. > > The -l=3Da type of construction allows the argument to be anything. > > Including it having a leading dash. > >=20 > > Second is the double-dash argument that stops words leading with dashes > > being parsed as options. > >=20 > > For instance; grep -- -v * > >=20 > > the -v is parsed as an actual string and not an option because it foll= ows > > the double dashes. >=20 > You miss the point, I believe. > The issue of *any* parser is only for the "flag" with optional > argument in their short-name form. > Because, as I explained above, the syntax for such cases is ambiguous. I'm going to have to disagree with you: this is software. You can **decide*= *=20 the rule and thus decide the parsing. Making the idea that it is ambiguous= =20 false. The rules I explained remove the ambiguity. It makes it extremely cl= ear=20 what happens. And that -S -2 example has a very clear behavior. The point of this bugreport is that my suggestion is that the behavior shou= ld=20 be changed to follow what most other software does. Doing; ls -I -v clearly understands that '-v' is not to be used as an optional argument. The reason, as far as I can tell, is that it does not fit as another argume= nt. The actual design of the arguments needs a bit of finesse, I agree. The '-d= -2'=20 example is really not the best UI design. Avoidance is best. Yes, usage of 'guix package [option] is stupid because it generates a lot o= f=20 cornercases here. Ideally it would be guix package list [options]. In general I do agree that your solution of dropping all optional short=20 arguments would be the best solution. They are extremely rare elsewhere. It would be a bit of a bigger project to make a nice UI without them, thoug= h. Please keep as the hard rule that the short version is an ALIAS to the long= =20 version. =2D-=20 Tom Zander