Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add setting to forbid numeric option names #18

Open
jwodder opened this issue May 1, 2023 · 1 comment
Open

Add setting to forbid numeric option names #18

jwodder opened this issue May 1, 2023 · 1 comment

Comments

@jwodder
Copy link

jwodder commented May 1, 2023

I'm using lexopt to write a command that supports negative numbers and dates (i.e., things starting with - and a digit) as arguments. If the user doesn't pass -- before such an argument, then lexopt treats, say, -1234 as the short option -1, and I have to use Parser::optional_value() to get the rest of the argument, append it to the -1, and parse the result. This works, but it's a little inconvenient, and it doesn't forbid arguments like -v1234.

I therefore request that lexopt add some setting (likely through a ParserBuilder) for not treating a hyphen followed by a digit as a short option. If you think this isn't sufficiently minimalist for lexopt, that's OK with me; I just thought I'd throw the idea out there.

@blyxxyz
Copy link
Owner

blyxxyz commented May 1, 2023

The current suggested workaround for this uses try_raw_args(), see examples/nonstandard.rs. (For your use case you'd want to get rid of .strip_prefix('-')?.)

But it's a little unwieldy and it's not too obvious and you're not the first one to want to handle -123 specially. So maybe it deserves more attention.

At a minimum I can call it out in the README as an example. (It's linked from the "Command line syntax" section but the description is on the cryptic side.)

A dedicated feature could be a setting or it could even be something else. Some considerations:

  • tail also handles -123, but it treats it as synonymous with -n 123, i.e. an option with a positive integer value; you treat it as a positional argument with a negative value. It would be nice to support both cases in one go.
  • Please provide way to parse -o=value as option taking value =value #13 is another pending request to add a setting. Whatever configuration system we pick should work for that case too.
    • For that case it would be more powerful to add a method to Parser instead of introducing a ParserBuilder type, so you can have different settings for different options.
  • Would a negative number be considered an option by Parser::values()? (This is the only method besides next() that tries to guess whether an argument is an option or a value based on its content.)
    • For your use case it should count as a value, but for tail it should count as an option.

Since there's a full workaround I'm not in a hurry to implement it but I will keep this issue open. Thanks for bringing it up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants