bug#40549: More usability issues:

[zimoun]

Dear Arne,


On Wed, 13 May 2020 at 20:53, Arne Babenhauserheide <address@hidden> wrote:
> zimoun <address@hidden> 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