From: zimoun <zimon.toutoune@gmail.com>
To: Arne Babenhauserheide <arne_bab@web.de>
Cc: 40549@debbugs.gnu.org, tomz@freedommail.ch
Subject: bug#40549: More usability issues:
Date: Thu, 14 May 2020 11:08:04 +0200 [thread overview]
Message-ID: <CAJ3okZ0NzNr88M-hKg5G9CcmwwDNCbTYzHpUq8x=58XNLUNvuA@mail.gmail.com> (raw)
In-Reply-To: <87o8qrwts1.fsf@web.de>
Dear Arne,
On Wed, 13 May 2020 at 20:53, Arne Babenhauserheide <arne_bab@web.de> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
> > It would like it works. And to do so, I accept that "guix package -I
> > regexp -p /tmp/profile" does not anymore and would be replaced by
> > "guix package -Iregexp -p /tmp/profile" which already works (as
> > specified by SRFI-37).
>
> Wow, this surprised me. I expected
>
> guix package -Iregexp
>
> to be equivalent to
>
> guix package -I -r -e -g -e -x -p
>
> which is how getopt long works in the shell.
I am not familiar with getopt but I think getopt does what the POSIX specifies.
Your expectation is legitimate when all the flags does not require a
mandatory argument. For example,
ls -artl
but it is not true when one of the flags requires one mandatory
argument, for example,
ls -aIrtl
then 'rtl' is seen as the argument of the option '-I, --ignore='.
Well, the correct is:
ls -aI '' -rtl
And the specification e.g., [1], says that "ls -aI'' -rtl" should too;
as for example "cut -f1 -d" and "cut -f 1 -d" both are allowed.
I should misread but all that perfectly works and is clearly specified
by SRFI-37. What is missing is the corner case: how to deal with
short-name option with optional argument? There is 2 incompatible
rules as I try to explain here [2]. The choice of the Guile
implementation leads to break the permutation rule for the short-name
with optional argument and maintain consistency with the space between
flag and argument. Another choice is to break the consistency with
the space between flag and argument and so it does not break the
permutation rule; as Tom mentioned with the Git example of
'-S[<keyid>], --gpg-sign[=<keyid>]'.
The issue is that the semantic of short-name of optional argument is
ambiguous considering all the other rules.
[1] https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
[2] http://issues.guix.gnu.org/40549#16
> > Instead of what I am proposing, what do you suggest?
>
> What I would suggets would break -Iregexp and as such deviate from
> SRFI-37, so it wouldn’t be optimal.
Just to note that the Guile implementation of SRFI-37 is "aware" of
this corner case as it is mentioned in their commentary, already said
here [3]. :-)
http://git.savannah.gnu.org/cgit/guile.git/tree/module/srfi/srfi-37.scm#n51
[3] http://issues.guix.gnu.org/40549#10
> It would first need another SRFI so it’s no shortterm fix :-)
From my point of view, different fixes are possible depending on what
we accept to break (here for "guix package" and probably similar cases
with other subcommand exist):
- nothing => improve the manual
- remove the short-name -u, -l, -d, -I, -A
- remove the argument for the short-name and keep it for the long-name only.
- remove '-X value' and allow only -'Xvalue' for X in {u, l, d, I, A}
=> new / amend SRFI-37
- other that my imagination is missing
Well, I have asked advices on guile-user [4]. I do not know if the
issue could be seen as a bug of SRFI-37.
[4] https://lists.gnu.org/archive/html/guile-user/2020-05/msg00034.html
> The commandline handling I want is this:
> https://www.draketo.de/english/free-software/shell-argument-parsing
Thank you for the link. For my understanding -- even after reading
the stackoverflow link -- your handling does not address the
short-name with optional argument. Does it mean you consider that
should not happen?
Best regards,
simon
next prev parent reply other threads:[~2020-05-14 9:09 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
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 [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ3okZ0NzNr88M-hKg5G9CcmwwDNCbTYzHpUq8x=58XNLUNvuA@mail.gmail.com' \
--to=zimon.toutoune@gmail.com \
--cc=40549@debbugs.gnu.org \
--cc=arne_bab@web.de \
--cc=tomz@freedommail.ch \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).