Support for single hyphen in long arguments

[kellpossible]

Maintainer's notes:

• This is blocked on pulling out the parser ([modular] Pull out a clap_lex #2915) so we can then abstract it and allow alternative syntaxes

---

Hi, I would like to begin porting a piece of command line software to rust which uses arguments of the style "-argument" with a single hyphen instead of the usual "--argument" with two hyphens preceding the name of the argument, I would like to use clap for parsing these arguments, but it sounds like clap does not yet support this functionality?

[kbknapp]

We had an issue open for this and it's...disappeared?

Thanks for (re)submitting! We'll need to go about the design of this a little bit because there were some open questions in the last discussion about this feature.

First and foremost, this will be an opt-in feature, probably via an AppSettings variant.

Now, once someone has opted-in, should -option style args be allowed with current double hyphen args (i.e. -option and --option), or should they disable/replace double hyphen longs?

Should they be allowed with -o shorts, or should they replace/disable single character shorts?

How should they interact with the current stacking of shorts? (i.e. right now if a CLI defines three shorts -a, -b, and -c, one could do $ prog -abcwhich is equivalent to$ prog -a -b -c`)

Once we get good answers on these questions we can start the implementation.

[kellpossible]

@kbknapp Hi! Yes that is strange that it disappeared!

In my particular use case, it would be fine for single hyphen -option to completely replace double hyphen --option longs, and to disable shorts and disable short stacking. I can see now this change has quite a few ramifications, sorry!

[kellpossible]

@kbknapp I would also be happy to help out with the implementation if it's not considered too complex for someone new to the project

[kbknapp]

@kellpossible I think this one will be a rather complex implementation, so I'd rather wait until 3.x where the internals are a little more clean and easy to work with.

I'm also good with it disabling double hyphen longs and stacking, although I'm ok with shorts still sticking around.

[kbknapp]

This could also play into my wanting to support Windows style CLIs where / is used instead of -...but I'm not ready to put in an issue for that though as there are a bunch of other things to do first 😉

[divagant-martian]

One way of achieving this would be to have "styles" for long and short versions, where this use case could use two styles "double hyphen" and "single hyphen" so that it is clear that --long-arg is still valid, or just "single hypen" to disable the first one. Somewhat related, thus commenting here.. I'd be interested too in being able to have argument values in the form argkey:value in a json style

[FibreFoX]

Is there any update on this one?

I need to have some kind of single hyphen "multi-char arguments" in order to comply to a given argument specification: https://developer.elgato.com/documentation/stream-deck/sdk/registration-procedure/#compiled-plugin-registration

These specifications require my application to accept single hypen arguments like myapp.exe -port 1234 -pluginUUID 14862781-8568-4472-bcfa-dffdeeaaec0d (...)

Would love to just be able to use clap on that one, but without the ability to somehow configure how many dashes/hyphens are used, it pushes me to use a different lib (if there are any for that use-case).

Maybe even when not having this supported (yet), maybe some additional note on the long-argument stuff would help to reduce searching this (and getting frustrated by that).

[epage]

As far as I'm aware, there was no work on this during 3.0's development and we are at this point prioritizing polish to get the the release out.

kbnapp previously said 3.0's code base should help. I wonder if #2915, with keeping this in mind, could make it even easier by offering lexing strategies. If we use a trait for this, then we could easily extend to any lexing style. This would be a big help for keeping the parser code understandable since it wouldn't need special cases for style and whether shorts are supported or not.

While not required, something also for us to consider is how to keep code size down with this. Any kind of flag-based runtime control will mean only a really powerful link-time optimizer would cut out the extra code. If we were okay with taking the lexing trait into the public API of clap, directly or indirectly, and if its object safe, we could accept a Box<dyn ArgLexer>. We could then store it in a enum Lexer { Box(Box<ArgLexer>), Owned(Default) } (to avoid the allocation on the default case). This means the default case only pays the price of dispatching on an enum.

[mkayaalp]

See #2468 for a collection of non-Unix examples that include:

• single hyphen: -option (qemu-like),
• slash: /? (Windows),
• colon option argument separator: argkey:value (json-like, also similar to Windows style as it happens)

[epage]

Yeah, going to go ahead and close this out in favor of #2468