From: zimoun <zimon.toutoune@gmail.com>
To: Tom Zander <tomz@freedommail.ch>
Cc: 40549@debbugs.gnu.org
Subject: bug#40549: More usability issues:
Date: Tue, 12 May 2020 20:08:32 +0200 [thread overview]
Message-ID: <CAJ3okZ16sBU0Pj+8Xeg_icNCGuonBxii9=pHZ6HZEnngk2=YQA@mail.gmail.com> (raw)
In-Reply-To: <1804825.CQOukoFCf9@cherry>
Dear Tom,
On Tue, 12 May 2020 at 18:23, Tom Zander <tomz@freedommail.ch> 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=1'.
> 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 ‘d ’".
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=LIST.
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 '='.
For short-name, it is ambiguous. Imagine that "guix package" has in
addition to '-S' the option '-2' meaning verbosity to level 2
(--verbosity=2). Then what is the meaning of:
guix package -S -2
?
Is it equivalent to
+ --switch-generation=-2
or
+ --switch-generation --verbose=2
?
> You asked for an example; see `git commit -S`. From the manpage:
>
> -S[<keyid>], --gpg-sign[=<keyid>]
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=4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3 -m 'init'
[master (root-commit) f4df0ff] init
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 bar
git config --global user.signingkey 4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3
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-argument
> > with both short and long name. It is a mistake to provide the short-name
> > for such case.
>
> 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.
It does not work for the general case as you describe. It is not so simple. :-)
Because '-d -1' means '--delete-generation=-1' and not '--delete-generation -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=-2d
or
+ --switch-generation --verbosity=2 --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** finds 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=a type of construction allows the argument to be anything. Including it
> having a leading dash.
>
> Second is the double-dash argument that stops words leading with dashes being
> parsed as options.
> For instance; grep -- -v *
> the -v is parsed as an actual string and not an option because it follows 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-line-
> argument that starts with a dash should be preferred to be an option. Only 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
next prev parent reply other threads:[~2020-05-12 18:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-11 9:23 bug#40549: [usability] revert last generation Tom Zander via Bug reports for GNU Guix
2020-04-23 19:37 ` Ludovic Courtès
2020-04-23 19:51 ` bug#40549: More usability issues: Tom via Bug reports for GNU Guix
2020-04-24 8:28 ` zimoun
2020-05-12 0:27 ` zimoun
2020-05-12 8:51 ` Ludovic Courtès
2020-05-12 9:54 ` Tom Zander via Bug reports for GNU Guix
2020-05-12 11:35 ` zimoun
2020-05-12 16:23 ` Tom Zander via Bug reports for GNU Guix
2020-05-12 18:08 ` zimoun [this message]
2020-05-12 20:19 ` Tom Zander via Bug reports for GNU Guix
2020-05-12 21:38 ` zimoun
2020-05-13 6:22 ` Tom Zander via Bug reports for GNU Guix
2020-05-13 16:32 ` Arne Babenhauserheide
2020-05-13 18:02 ` zimoun
2020-05-13 18:53 ` Arne Babenhauserheide
2020-05-14 9:08 ` zimoun
2020-05-12 14:10 ` zimoun
2020-05-12 10:38 ` zimoun
2020-05-12 13:58 ` zimoun
2020-05-14 8:15 ` Efraim Flashner
2020-05-14 9:13 ` zimoun
2020-05-14 14:25 ` bug#40549: Fix -p profile -p profile -I zimoun
2020-05-12 13:03 ` bug#40549: proposal for 'process-actions' zimoun
2020-05-12 16:26 ` Tom Zander via Bug reports for GNU Guix
2021-09-08 12:49 ` bug#40549: [usability] revert last generation zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ3okZ16sBU0Pj+8Xeg_icNCGuonBxii9=pHZ6HZEnngk2=YQA@mail.gmail.com' \
--to=zimon.toutoune@gmail.com \
--cc=40549@debbugs.gnu.org \
--cc=tomz@freedommail.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).