From debbugs-submit-bounces@debbugs.gnu.org Tue May 12 14:08:52 2020 Received: (at 40549) by debbugs.gnu.org; 12 May 2020 18:08:52 +0000 Received: from localhost ([127.0.0.1]:56480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYZKl-00034P-TP for submit@debbugs.gnu.org; Tue, 12 May 2020 14:08:52 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:42099) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYZKk-00034C-1h for 40549@debbugs.gnu.org; Tue, 12 May 2020 14:08:50 -0400 Received: by mail-qt1-f169.google.com with SMTP id x12so11894801qts.9 for <40549@debbugs.gnu.org>; Tue, 12 May 2020 11:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pF5zYgaQ5M3r5xolYm/CH9Dz6fMhxYbeQi8wsNVLJpc=; b=edBdBQBIxdurZLS447l1wGjTkQzBN8ViwnYw95lHGBRc6vzSpYfDXd/dbK9ewi3YIy l8wgjuRmmG6gpv1KFPmCpptdO4u3x7oXL8/lgo6wtecq8kBXaZ2/ykanRpCe41tFbKKr RP8hA8GRFlxRicZj15WL9SmWdVt6tVDNsn8HFsLu7Ivr2DdeOKWDaxBC0zCsgq73azSJ WG+W8ZZW2vLCug4lSLQVXdwRy7GybvzZ6XeFRZDOU9s9qKwCgToF5Z0MWYPwQiBzxhvQ IzPBHCmKK2NbXeIj/n4jOiZ5VS4Sh7EwxOpZON+nlLXvRhQHlcuF/jGpHaroYp81GZH7 fLGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pF5zYgaQ5M3r5xolYm/CH9Dz6fMhxYbeQi8wsNVLJpc=; b=p9H2uTeDIf7leSyLGyDNq/nlWdU/03523IF8SDn2XKKTTqnMUem30xxWP+RcS6xeED seAv8SqFY3OhTZzU55evOBS9p//2QDPhnFodctpQqjkcLbPVlqYb8CAqRuRLp86ThdRb XyGCGyhFdcpfk8SX/ZcvmzRIGkIUXRm59owzrdinh4YDkdYW5ZiX7uCp2ryHCwOVYScy 1Gt6uSennwWdStkcpKPiWe91DILdJ3Ou0uaPO+lqmLm1dVE57ZcyuVcPB6t3Z/XAkNeJ 1V0erivhAKUY2EroyHZKclsZ1Ygm4LffGXSIPP5ToYParwl13N0e4xXe3V8xIRP98ZUV QqiA== X-Gm-Message-State: AGi0PuaflKnRuonKQvwbFGpP9/CPKNnzuSmf8BIz8PPPcw47rLaVbJW2 dA49ED02knVXz6jhKhE6eh4bZZWXD6xIVJ+jpb7F3lMI X-Google-Smtp-Source: APiQypI8qYOx1QKS/jRXOCddZhTr49svoe3Cq6SYQz0m7e6zvvs4Em1YlvV99U1sChiUkv9SYcPEqNX7vl9Eb1Pmkcg= X-Received: by 2002:ac8:2db0:: with SMTP id p45mr20735487qta.354.1589306924154; Tue, 12 May 2020 11:08:44 -0700 (PDT) MIME-Version: 1.0 References: <6171889.DvuYhMxLoT@cherry> <5652466.lOV4Wx5bFT@cherry> <1804825.CQOukoFCf9@cherry> In-Reply-To: <1804825.CQOukoFCf9@cherry> From: zimoun Date: Tue, 12 May 2020 20:08:32 +0200 Message-ID: Subject: Re: bug#40549: More usability issues: To: Tom Zander Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40549 Cc: 40549@debbugs.gnu.org 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 (-) Dear Tom, On Tue, 12 May 2020 at 18:23, Tom Zander wrote: > The other is the ordering of arguments being parsed unpredictable. > The usecase given was the `-d 1 -S 2` arguments (see earlier emails for > details). Fix for that coming soon. :-) Thank you for the report. > > Please could you indicate me command-line tools where short-option > > with optional-argument is possible. > > Because if there is one, I could have inspiration to know how it > > resolves the ambiguity. > > The design of the short options is that it is an alias. Identical to the > software regardless of what the user typed. 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. > So you get 'cut --field 1' or 'cut -f1' or 'cut -f 1' or 'cut -f=3D1'. > All identical. > The important part here is that each _option_ is written separately, with= a > leading dash. And try "cut -f -d' '", it raises the error "cut: invalid field value =E2= =80=98d =E2=80=99". 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. 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 addition to '-S' the option '-2' meaning verbosity to level 2 (--verbosity=3D2). Then what is the meaning of: guix package -S -2 ? Is it equivalent to + --switch-generation=3D-2 or + --switch-generation --verbose=3D2 ? > You asked for an example; see `git commit -S`. From the manpage: > > -S[], --gpg-sign[=3D] Thank you for the example. Let me show you that it raises an issue too because it is not so "simple". :-) --8<---------------cut here---------------start------------->8--- mv ~/.gnupg ~/.gnupg.bak gpg --gen-key gpg --list-keys mkdir -p /tmp/foo touch /tmp/foo/bar git -C /tmp/foo init git -C /tmp/foo/ add bar git commit -S -m 'init' error: gpg failed to sign the data fatal: failed to write commit object git -C /tmp/foo commit -S 4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3 -m 'init= ' error: pathspec '4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3' did not match any file(s) known to git git -C /tmp/foo commit --gpg-sig=3D4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3 -m 'init' [master (root-commit) f4df0ff] init 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 bar git config --global user.signingkey 4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B= 3 echo ok > /tmp/foo/bar git -C /tmp/foo commit -S -am 'bis' [master 639c41e] bis 1 file changed, 1 insertion(+) --8<---------------cut here---------------end--------------->8--- Maybe Git manual is lying. ;-) > > The issue is that Guix uses a bad practise: option with optional-argume= nt > > with both short and long name. It is a mistake to provide the short-n= ame > > for such case. > > It looks like the parser could be improved by preferring to see any argum= ent > with leading dash as a option when it **might** be an argument. It does not work for the general case as you describe. It is not so simple= . :-) Because '-d -1' means '--delete-generation=3D-1' and not '--delete-generati= on -1'. So considering the situation '-d -X', the parser needs to guess if '-X' is the argument of the option '-d' or if it is another option. Yes, it is possible but it is not so easy -- nor impossible -- because what does it means '-S -2d'? + --switch-generation=3D-2d or + --switch-generation --verbosity=3D2 --delete-generation From my knowledge, all that is solved by the rule: no short option with optional argument. > So; if you type -`guix package -l --help` then your parser **first** find= s 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. > > 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. Inclu= ding it > having a leading dash. > > Second is the double-dash argument that stops words leading with dashes b= eing > parsed as options. > For instance; grep -- -v * > the -v is parsed as an actual string and not an option because it follow= s the > double dashes. 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. Otherwise, the parser really behaves as you expect! > > Now all this is clearer for me and I do not think it is a fixable bug. > > It is, just follow the suggestion from me and from zimoun: any command-li= ne- > argument that starts with a dash should be preferred to be an option. Onl= y in > a second phase do you try to match anything to (optional) options. You are referring these lines [1] from me, right? --8<---------------cut here---------------start-------------->8--- srfi-37 should consider that if an argument starts with dash, then it is not an argument and turn it into an option. --8<---------------cut here---------------end--------------->8--- I thought that and then I tried to fix it in the Guile implementation of SRFI-37 [2] and I learned [3] that it is not so simple, as I explained to you above. [1] http://issues.guix.gnu.org/40549#7 [2] http://git.savannah.gnu.org/cgit/guile.git/tree/module/srfi/srfi-37.scm [3] http://issues.guix.gnu.org/40549#10 > As stated, the rest of the world does this, please check out the various > examples I gave here to confirm that others have solved it and it may be > possible to solve it for guix too. Please consider that some people here are long standing GNU hackers. :-) So they might be the same ones that implemented the "rest of the world" too= . ;-) All the best, simon