Support `=` (equal sign) as value separator in argument syntax

[sandreas]

Details

Most command line parsers support various types of argument syntax, which you delightfully described here: https://github.com/Tyrrrz/CliFx#argument-syntax

I'm missing the style --parameter=value (which results in the same as --parameter value). Not sure, if there is a reason to ommit it, but most other command line parser libs I used do support it.

It's not a huge deal, but a little user experience issue (I'm trying to port a command line tool not having to change all scripts using it).

What do you think?

[Tyrrrz]

I don't have a very strong argument against it, but I generally wanted to limit alternative ways of doing the same thing. The space delimited syntax seems more common and in some cases also more powerful.

For example, you can specify multiple values with --parameter value1 value2 value3, how would you do the same with equals sign? I know different parsers take different approaches here.

[sandreas]

I generally wanted to limit alternative ways of doing the same thing.

Perfectly fine. Your library is just an awesome piece of software and I can tell that not only reading your docs or answers, but also by reading your API methods and your code. Very professional - I also like CliWrap very much.

The space delimited syntax seems more common and in some cases also more powerful.

Absolutely.

For example, you can specify multiple values with --parameter value1 value2 value3, how would you do the same with equals sign?

My best bet would be --parameter=value1 --parameter=value2 --parameter=value3 not having a possibility to prevent multiple repetitions of --parameter. I also saw things like --parameter=value1,value2,value3 combined with a separator char attribute (CommandOption("parameter", "p", ",")), but i don't like this approach, because if you would like to provide a real ,, you have to work with escaping, etc.

One problem I really see with the current approach is user expectations combined with the error message when using =. I wrote a little tester app and called it like this:

./tester tag --meta-title="my title"

and got

Unrecognized option(s):
--meta-title=my title

tester v1.0.0

USAGE
  dotnet tester.dll tag [options]

OPTIONS
  --meta-title      Default: "".
  -h|--help         Shows help text. 

It took me a while to understand, that = is not supported, that the error points me to the unrecognized option --meta-title=my title referring the whole thing as ONE option, not as option with parsed value. I first thought, that the library had a parsing issue. It just looks strange to see --meta-title=my title unrecognized and later on there is --meta-title in the usage instructions :-)

Maybe it would be helpful to extend the error message, if there is an = used in an option like this:

Unrecognized option(s):
--meta-title=my title (Please note, that = is not supported as option separator)

Don't get me wrong, the library is perfectly usable as is. If everyone else hat implemented it as clean as you did (without = support), I would not have been suprised, that = is not supported :-)

[Tyrrrz]

Thanks!

Yeah, that's a good idea. Maybe if the supplied argument contains an equals sign, we can provide an additional hint.

Alternatively we can just extend that error messages with an example of how options should be formatted.

[Tyrrrz]

Descoping this