[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40549: More usability issues:
From: |
Tom Zander |
Subject: |
bug#40549: More usability issues: |
Date: |
Tue, 12 May 2020 18:23:13 +0200 |
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
- bug#40549: More usability issues:, zimoun, 2020/05/11
- bug#40549: More usability issues:, Ludovic Courtès, 2020/05/12
- bug#40549: More usability issues:, Tom Zander, 2020/05/12
- bug#40549: More usability issues:, zimoun, 2020/05/12
- bug#40549: More usability issues:,
Tom Zander <=
- bug#40549: More usability issues:, zimoun, 2020/05/12
- bug#40549: More usability issues:, Tom Zander, 2020/05/12
- bug#40549: More usability issues:, zimoun, 2020/05/12
- bug#40549: More usability issues:, Tom Zander, 2020/05/13
- bug#40549: More usability issues:, Arne Babenhauserheide, 2020/05/13
- bug#40549: More usability issues:, zimoun, 2020/05/13
- bug#40549: More usability issues:, Arne Babenhauserheide, 2020/05/13
- bug#40549: More usability issues:, zimoun, 2020/05/14
- bug#40549: More usability issues:, zimoun, 2020/05/12
bug#40549: More usability issues:, zimoun, 2020/05/12