Parameters seem to behave differently in the latest version

[alexfalkowski]

Hi,

I have an app that uses PowerArgs. The usage looks like the following:

Usage: spec options

OPTION TYPE POSITION DESCRIPTION

-path (-p) String 0 The path to search all the Spec assemblies. The default is spec.

-example (-e) String NA The example to execute. This could be a spec, example group or an e
xample.
-pattern (-P) String NA Load files matching pattern. The default is Specs.

-output (-o) String NA The output path of the test results. The default is test-results.xm
l.
-format (-f) ConsoleFormatterType NA Specifies what format to use for output.

-dryrun (-d) Switch NA Invokes formatters without executing the examples.

-version (-v) Switch NA Display the version.

-colour (-c) Switch NA Enable colour in the output.

-help (-h) Switch NA You're looking at it.

EXAMPLE: spec.(exe|sh) spec
Execute all the specs in the folder spec.

I use to be able to run the program as spec.exe artifacts -P Unit.Specs. Now I get

Unexpected Argument: artifacts

Now if I run spec.exe -p artifacts -P Unit.Specs it tells me

Argument specified more than once: path

So this is treating it as -p and -P as the same option, which I am guessing is incorrect.

The only way for me to get it working is to specify the long form:

spec.exe -path artifacts -pattern Unit.Specs

Hopefully this highlights my issues:

[adamabdelhamed]

By default, PowerArgs is case insensitive, but there is a way to change it. Can you try to put the [ArgIgnoreCase(false)] attribute on your class and see if that helps? That will force all of your usage to be case sensitive.

It might actually have been a bug that it worked before. I would have expected you to get an InvalidArgDefinitionException, but it looks like my verification code doesn't check for shortcuts that are the same when you ignore case.

[adamabdelhamed]

After more investigation, I am sure about this. Your code should have never worked without that attribute. -p and -P are the same. I've already coded a fix that will throw an InvalidArgDefinitionException in this case for my next check in. I'll leave this issue open until then.

Let me know if you have any more questions or suggestions on this issue.

Thanks,
Adam

[alexfalkowski]

So my first paramater is called Path with arg position of 0 I don't want it to have a shortcut and then I have a parameter called Pattern this is set to shortcut to P. When I add the attribute I get

Duplicate arg options with shortcut P

Is this expected behaviour?

Alex

[adamabdelhamed]

You have a few options here.

1 You can add [ArgShortcut(null)] to a property which will mean it has no shortcut. 

2 You can specify a shortcut like [ArgShortcut("pa")] for one and [ArgShortcut("p")] for the other to avoid the conflict.  

3 You can remove the ArgShortcut attributes altogether and let PowerArgs come up with defaults that don't conflict (in this case it will choose "p" for the first property it finds and "pa" for the second).

[alexfalkowski]

Thanks mate :)

[adamabdelhamed]

No problem. This is inspiring me to make sure I flag more of these potential issues in my validation code. Thanks for reporting it.

[alexfalkowski]

Another thought I had was rather than having ArgShortcut and pass null. Maybe have a class called ArgNoShortcut as I personally hate passing in null. This makes it more explicit.

[adamabdelhamed]

I'm not a huge fan of adding additional surface area where it's not needed. What about a middle ground. ArgShortcut could have a constant defined called ArgShortcut.NoShortcut. You could then pass that to the ArgShortcut attribute. It would be as explicit as the ArgNoShortcut class without adding a new type.

[alexfalkowski]

I'm happy with that just thought it would be less typing with a new type. So the class now would take either an enum or a string?

[adamabdelhamed]

Yup. I'm thinking something like [ArgShortcut(ShortcutPolicy.NoShortcut)].

[alexfalkowski]

Awesome looking forward to it :)

[adamabdelhamed]

It's in. ArgShortcutPolicy.NoShortcut,