all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tom Zander via Bug reports for GNU Guix <bug-guix@gnu.org>
To: zimoun <zimon.toutoune@gmail.com>
Cc: 40549@debbugs.gnu.org
Subject: bug#40549: More usability issues:
Date: Tue, 12 May 2020 18:23:13 +0200	[thread overview]
Message-ID: <1804825.CQOukoFCf9@cherry> (raw)
In-Reply-To: <CAJ3okZ0wZTqKAoC8ZJt=G67Mm0zBRE=n08B9r71irYkYLfnDWg@mail.gmail.com>

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
> 
> <bug-guix@gnu.org> 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






  reply	other threads:[~2020-05-12 16:23 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 [this message]
2020-05-12 18:08               ` zimoun
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1804825.CQOukoFCf9@cherry \
    --to=bug-guix@gnu.org \
    --cc=40549@debbugs.gnu.org \
    --cc=tomz@freedommail.ch \
    --cc=zimon.toutoune@gmail.com \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.