IMO I much prefer having: --member=member1,member2
vs: --member=member1 --member=member2 The latter can leave me wondering if subsequent values are additive or actually override prior ones. --Jens On Thu, Apr 20, 2017 at 1:37 PM, Jinmei Liao <jil...@pivotal.io> wrote: > In the effort of adding option validation to gfsh commands (GEODE-1597) and > simplifying gfsh parsing, I started this exercise of only using > SpringShell's parser instead of a combination of springshell's, > joptsimple's and our own parsers. The end result is a lot more manageable > code base, and the capability to validate the option list, but does have > these following different behaviors, and I would like the community's wight > in on whether or not these are acceptable or not: > > 1) SpringShell doesn't allow you to specify an option twice, so for > multivalued parameters, our old parser can accept command like > > "change loglevel --member=member1 --member=member2", > > but now the parser will give you an error, and you should only do > "change loglevel --member=member1,member2". > > The new parser did something speical for --J option though, so for --J, you > can specify it multiple times. > 2) For value separator, springShell default's to ",", you can only > overwrite it with option context "splittingRegex", we do not honor the > @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for > separators, so this won't break our commands, but if there is any command > out there that would define a different @CliMetaData(valueSepartor=) other > than ",", SpringShell would not know how to parse it. > 3) To specify empty string as parameter value, before you will need to do > > put region=A key="''" value="''" > > spring shell would think the value you are trying to pass in are two single > quotes instead of empty strings, now, you should only do > > put region=A key="" value="" > > Cheers > > Jinmei >
