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 > > 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[], --gpg-sign[=] > 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