Hi everyone. I need to parse single-hyphen long arguments (
-help as opposed to
-h) in my project for compatibility. Normally I would've used clap, but single-hyphen long arguments are not supported (it's a planned feature if I recall correctly). I've been trying to find if there are other crates that can do this easily, but i found this weirdly hard to do.
In any case, I'm wondering now what the best way to go about doing this for me might be. I could make a parser myself, but I don't know what kind of system I can come up with to deal with like 70 different arguments in a clean way, and I do need to move on to the rest of the project. I really like that using derive macro in clap results in pretty much self-documenting code, so I kinda want that but it's not necessary.
So my question is:
- Is there another crate where this is easier? Some crates are able to handle this but in a very hacky way, and I think I'd just implement one myself at that point.
- If I were to make one myself, how should I structure it?
Thanks in advance!
This issue looks very much opposed to the idea. But it's from 2020, so maybe today maintainers are open to extending clap in that regard.
I wonder if it is as easy as patching clap by changing the
Arg::short field to
Option<Str> and the
s argument's type of the
Arg::short method to
If I remember correctly, short arguments can be chained (
-a -b -c is equivalent to
-abc) so I'm assuming that's the reason they're opposed to that idea. What I want however is a slightly different concept (short arguments would not exist) and is discussed here.
I don't think using clap's short arguments would really work, because of the chaining thing I mentioned above, they're parsed differently.
Maybe I am nuts?
Could you wrap the
get_matches call to
env::args_os and just add a hyphen to the single hyphens?
Of course that will break your --help and error output..
An option could be to use something like lexopt. I don't know if it does single dash multi character options, but it is very basic and low level and it shouldn't be hard to make a variant of it with such support.
I too have run into issues trying to be compatible with existing command syntaxes (not in this specific way thankfully), that led to me having to fight the command line parser libraries (specifically I managed to shoehorn bpaf into doing what I wanted).
I also believe uutils (reimplementation of GNU coreutils) had issues with making compatible parsers, might be worth checking out how they solved it. In particular, parsing the syntax of dd would be interesting.