bug#40549: More usability issues:

[Tom Zander]

On dinsdag 12 mei 2020 13:35:04 CEST zimoun wrote:
> On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
> 
> <address@hidden> wrote:
> > the bugreport is a usability bug which stems from the fact that the
> > command
> > line parser behaves differently from every single other commandline parser
> > average people like me have ever used.
> > 
> > A near 100% of the command line tools on your Gnu/Linux box will behave
> > differently than guix does now.
> > 
> > C apps using libc, python apps using their parser, even C++ apps using the
> > Qt commandline classes, all are generally compatible with regards to
> > behavior.
> > 
> > Only Guix is different.
> 
> Could you provide concrete examples?  Other than "guix package"?
> And other than short-option with optional argument?

This report lists two items.

Indeed the short options are a good one. It is unheard of to have an alias not 
be an alias but behave differently.
It also can't be said to be documented as the --help output does not actually 
state this. I only learned this difference today :-)

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).


> 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.

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.

When you talk about flags you can group them. `mv -vufi` is again identical to
`mv -v -u -f -i`.  But this is irrelevant to your question because, as stated, 
this is about _flags_, not option.

You asked for an example;  see `git commit -S`. From the manpage:

   -S[<keyid>], --gpg-sign[=<keyid>]


> 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.

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.

> 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.

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.
-- 
Tom Zander