Support for --cflags style option parameters, unit test, fixes #174

[tonylukasavage]

Based on the discussion already in #174, I removed the extra validation in required options so that they could handle cflag style option parameters. I also modified the normalize() function so that no additional normalization is performed on arguments following a require option. This accounts for a case like this:

COMMAND --cflags "-DDEBUG" 

without adjusting the normalization code, that would be normalized to:

COMMAND --cflags -D -D -E -B -U -G

but with the changes in this pull request it is handled appropriately.

All unit tests, included the one I added for this particular scenario, pass.

[tj]

hmmm not sure how I feel about it since -DEBUG on its own wouldn't be legal (if not following another flag etc), might lead to some weird confusion but probably not a huge deal

[tonylukasavage]

@visionmedia -DEBUG isn't meant to be legal on its own, nor should it be. It's supposed to be literal input to the require option. I would imagine in almost all cases the CLI would wrap the arguments to the required option like this:

COMMAND --cflags "-DDEBUG -DSOMETHINGELSE" --other -yxz

It would think the potential confusion would be minimal, as anyone encountering the syntax would be using a project in which that syntax is known and defined. If I'm using a CLI tool for a project I know accepts cflag style options, I don't think seeing --cflags -DDEBUG would be off-putting. That said, I was personally stylistically encourage the use of quotes around the value.

[tonylukasavage]

@visionmedia I had another idea, but I didn't want to take the time to implement it without your input. I thought rather than as a rule having all required options take the next argument as a literal, perhaps there could be a config option (like flag, description, coerce, default) for options to indicate that they should take the next argument as a literal, only in that case would they avoid the additional optionMissingArgument() check, avoiding confusion in all but the specifically designated cases.

I didn't want to screw with your current option() format though without seeing how you thought that might be done, since its style for me is one of the high points of this module. Essentially, you'd be able to specify in the option() call that this particular option takes the next argument as a literal no matter what it is. Personally, I think that required options are enough to indicate that, but if you feel there would be confusion, perhaps this would be a positive compromise.

Thoughts?

[tonylukasavage]

Any thoughts here @visionmedia? I'd love to use commander in our current project, but this is a blocker for our purposes. Again, I'd be happy to implement the alternative I mentioned as well.

[tj]

ill merge for now it should be ok