bug#27820: guix package -u: order of argument is significant

[Mark H Weaver]

Ricardo Wurmus <address@hidden> writes:

> Ludovic Courtès <address@hidden> writes:
>
>> Ricardo Wurmus <address@hidden> skribis:
>>
>>> Ludovic Courtès <address@hidden> writes:
>>>
>>>> Mark H Weaver <address@hidden> skribis:
>>>>
>>>>> I agree that this is quite confusing.  Perhaps we should issue a warning
>>>>> if the regexp begins with "-".
>>>>>
>>>>> Also, perhaps we should *always* require an argument after "-u", even if
>>>>> "-u" is at the end of the command line, failing otherwise.  Users would
>>>>> then learn to always pass an argument to "-u", and thus would be less
>>>>> likely to fall into this trap when adding more options after the "-u".
>>>>
>>>> I’m in favor of the former:
>>>>
>>>> diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
>>>> index 8da7a3fd3..b6133b6af 100644
>>>> --- a/guix/scripts/package.scm
>>>> +++ b/guix/scripts/package.scm
>>>> @@ -486,6 +486,11 @@ Install, remove, or upgrade packages in a single 
>>>> transaction.\n"))
>>>>                               arg-handler))))
>>>>           (option '(#\u "upgrade") #f #t
>>>>                   (lambda (opt name arg result arg-handler)
>>>> +                   (when (string-prefix? "-" arg)
>>>> +                     (warning (G_ "upgrade regexp '~a' looks like a \
>>>> +command-line option~%")
>>>> +                              arg)
>>>> +                     (warning (G_ "is this intended?~%")))
>>>>                     (let arg-handler ((arg arg) (result result))
>>>>                       (values (alist-cons 'upgrade arg
>>>>                                           ;; Delete any prior "upgrade all"
>>>>
>>>> Thoughts?
>>>
>>> This seems good to me.  I just wonder if there are legitimate cases
>>> where a package regexp would look like a command line option.  If that’s
>>> not the case could we just “unread” the argument and parse it as the
>>> next option?
>>
>> I thought about it but in theory “-” is perfectly legitimate, so I
>> thought we’d rather not try to be smart.  Thoughts?
>
> Is it really legitimate?  The regular expression is supposed to match on
> package names and we have no packages starting with “-”.

The provided regexp is not necessarily intended to match at the
beginning of the package name.  For example, suppose that someone wants
to upgrade both variants of python-six, i.e. {python,python2}-six.  An
easy way to ask for this would be to write:

  guix package -u -six

For comparison, this is how the well-known "grep" program treats
arguments to its '-e' option:

  address@hidden ~$ echo "python2-six" | grep -e -six
  python2-six

> And even if we did (or the user has some oddly named packages in
> GUIX_PACKAGE_PATH), they could write “^-”.

And in this case, they could write:

  guix package -u "()-six"

to work around cleverness on our part.

> Or we could demand that the argument be quoted (“'--foo'” or
> “"--foo"”) in that case.

That wouldn't work, because in general quoting is handled by the shell,
not the program.  We never see those quotes, and have no way of knowing
whether or not they were present.

If we *do* see quotes, it means that the user wrote something like this:

  guix package -u '"-six"'

in which case an experienced POSIX user would expect the quotes to be
included in the regexp.  That's how POSIX programs behave in practice.

> It just seems like a really rare edge case to *want* it to behave as it
> does now.

I don't feel strongly about it, and so I'm glad to go along with
whatever you and Ludovic can agree on.  I can appreciate the arguments
on both sides.

     Thanks,
       Mark