Ricardo Wurmus <[email protected]> skribis: > Ludovic Courtès <[email protected]> writes: > >> Mark H Weaver <[email protected]> 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? Ludo’.
