Support for single hyphen in long arguments

[epage]

Issue by kellpossible
Sunday Mar 18, 2018 at 06:17 GMT
Originally opened as clap-rs/clap#1210

---

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?

[epage]

Comment by kbknapp
Monday Mar 19, 2018 at 18:12 GMT

---

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.

[epage]

Comment by kellpossible
Monday Mar 19, 2018 at 22:55 GMT

---

@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!

[epage]

Comment by kellpossible
Monday Mar 19, 2018 at 23:04 GMT

---

@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

[epage]

Comment by kbknapp
Monday Mar 19, 2018 at 23:55 GMT

---

@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.

[epage]

Comment by kbknapp
Monday Mar 19, 2018 at 23:55 GMT

---

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 😉

[epage]

Comment by divagant-martian
Sunday Jan 05, 2020 at 14:19 GMT

---

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

[epage]

Comment by FibreFoX
Monday Nov 01, 2021 at 21:12 GMT

---

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]

Comment by epage
Monday Nov 01, 2021 at 21:38 GMT

---

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.

[epage]

Comment by mkayaalp
Sunday Nov 14, 2021 at 22:26 GMT

---

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)