0

I am currently using NDesk.Options to manipulate my command line arguments. The problem I encountered now is that when I run with multiple flags, the computation is done in the order the flags appear. But this is not always what I want. For example for these arguments

-t 20 -g mailGroup

I want first the -g flag to be computed (which loads a mailGroup data) and just after it to compute the -t 20 (which is top 20 of some analysis). This works "-g mailGroup -t 20"

Also, my -t 20 will not work if nothing is loaded, so basically the -g mailGroup is a needed option before -t 20.

Is there an elegant way to provide priority of evaluation for these flags ? Also maybe dealing with the cases that one flag requires the existence of a subset of another flags to be computed before it (like for example I have multiple ways and forms of loading, not just -g).

user3828757
  • 3
  • 1

1 Answers1

1

Are you performing logic in the action for each option (ie. at the same time you read each new option)? If so, decouple and simply set boolean/config variables within the actions, then do your logic after all options are parsed.

codenheim
  • 20,467
  • 1
  • 59
  • 80
  • Yes, I am doing action for each option. The action consists of a method call for example, looks quite neet. So you are saying instead of that, set a boolean that this function has to be run, and afterwords deal with the order when all booleans are set after options.Parse(args) ? – user3828757 Jul 11 '14 at 09:52
  • Yep, that how I do it. I have a bunch of variables in my main, and all of my actions just set the variables. Once I'm done, I use logic (if/switch statements) based on those variables, and you can check for mutual exclusivity, or nest them for dependencies. – codenheim Jul 11 '14 at 09:54
  • Great, sounds like a plan, Ill try it now than :D. I thought NDesk.Options library can deal with some of those cases, that's why I didn't wanted to make my own logic around it, when I have (most probably) a better one in the library. – user3828757 Jul 11 '14 at 09:58
  • Its just like delaying type resolution in a compiler by making it a 2-pass compiler. Parse in pass 1, resolve or execute semantic actions in phase 2. I still like NDesk.Options because it is a concise and robust way to handle options. This also lets you handle duplicate or cumulative options like -v -v -v (verbose level 3 if your action is => verbose++) – codenheim Jul 11 '14 at 10:09