bug#40549: More usability issues:

[zimoun]

Dear Tom,

On Tue, 12 May 2020 at 18:23, Tom Zander <address@hidden> 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