On Wed, Jan 14, 2026 at 11:10:43AM +0100, Neal H. Walfield via devel wrote: > Hi Björn, > > Thanks for your comments. > > On Mon, 12 Jan 2026 18:39:55 +0100, > Björn Persson wrote: > > Neal H. Walfield via devel wrote: > > > As far as I can tell, gpgv cannot be convinced to do the right thing. > > > > Thank you for illustrating how confusing an idiosyncratic command line > > syntax can be. Allowing parameters in any order would be more user- > > friendly. > > > > There are lots of other programs that also require parameters in a > > particular order, and expect the user to know the correct syntax. > > Sequoia is one of them. This does not work: > > > > $ sq --signer-file ./fedora.gpg verify --cleartext > > Fedora-Workstation-43-1.6-x86_64-CHECKSUM > > error: unexpected argument '--signer-file' found > > > > tip: a similar argument exists: '--password-file' > > > > Usage: sq <COMMAND> > > > > For more information, try '--help'. > > Thanks for raising this issue. I'd like to dig a bit deeper here so > that we can improve Sequoia. I'm not convinced that allowing > parameters in any order would be more user friendly. Some ordering is > required for an argument that takes a value. Consider: > > command --output file > > command file --output > > In the second invocation of command, I would find it surprising to > learn that file is --output's value. > > Also, I think subcommands should be ordered. Consider: > > sq key generate ... > > sq generate key ... > > sq considers the first variant to be valid and the second to not be. > I'd personally be quite surprised if a tool allowed an arbitrary > ordering here. > > In your example you seem to suggest that subcommand-specific > parameters should be allowed before the subcommand. I could imagine > doing that, but that seems idiosyncratic. It's not the default in > clap, which is what Sequoia uses to parse arguments and which is a > widely used command line argument parser in the Rust ecosystem. Also, > Sequoia acts similarly to other tools in this regard, like git: > > $ git --pretty=oneline log > unknown option: --pretty=oneline > usage: git ... <command> [<args>] > > And cvs: > > $ cvs -h log > cvs: invalid option -- 'h' > Usage: cvs [cvs-options] command [command-options-and-arguments] > > So it seems surprising to me to say that Sequoia is idiosyncratic. > > Perhaps the output would be less confusing if sq identified that the > argument is out of order and displayed a message suggesting that the > user reorder the option. > > What do you think? How could we make sq less confusing?
JFTR (obviously I am not Björn), another point of view, much closer to yours: I personally believe that options that only affect the behavior of options specified later on the command-line (such as tar's -C or gcc's -I/-L) may be confusing, and options should be able to be specified in any order... ...except for two cases: - IMHO, positional arguments shoud strictly come after optional ones, I am old-school on that (and yes, I know <up-arrow>-l after ls can be convenient, but the risk of misinterpreting positional arguments that start with a dash can be worse) - if a program has subcommands, then the options for the subcommand should most definitely come after the subcommand itself, if only because different subcommands accept different options, and some may not be valid for that specific subcommand at all, and the parser should be able to figure that out as early as possible before getting confused So yeah, `sq <common options> verify <verify options>` seems perfectly reasonable and correct to me :) G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
