You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PowerArgs allows options of type List<> to have 0, 1, or more argument values. However, if a List<> option is followed by another option on the command line, and the List<> option contains zero argument values, then PowerArgs parses the next option's key as an argument value of the preceding List<> option, which is undesired behavior.
For example, consider the following two options:
[ArgDescription("Specify 0, 1, or more comma- or space-separated strings.")]
public List<string> AlphaList { get; set; }
[ArgDescription("Specify a flag.")]
public bool BetaFlag { get; set; }
When specifying 1 or more argument values for -AlphaList, PowerArgs recognizes that the argument value list terminates at the next option, -BetaFlag:
command.exe -AlphaList first -BetaFlag ==> AlphaList = {"first"}
command.exe -AlphaList first second -BetaFlag ==> AlphaList = {"first", "second"}
command.exe -AlphaList first second third -BetaFlag ==> AlphaList = {"first", "second", "third"}
Those all work as desired: -BetaFlag appears to be recognized as a terminator for the preceding option's parameter list.
However, when there are 0 argument values for -AlphaList, PowerArgs fails to recognize -BetaFlag as a terminator:
In this case, the string "-BetaFlag" is interpreted as an argument value of -AlphaList. This is undesirable behavior: it is inconsistent with the behavior above, and typically causes the application to fail out.
It's unfriendly to end users to expect them to know these, or to try to explain it to them in the command help. The second workaround also prevents multiple empty list options from being specified: only one option can be at the end of the command line, so other list options would require the first workaround as well.
The text was updated successfully, but these errors were encountered:
PowerArgs allows options of type List<> to have 0, 1, or more argument values. However, if a List<> option is followed by another option on the command line, and the List<> option contains zero argument values, then PowerArgs parses the next option's key as an argument value of the preceding List<> option, which is undesired behavior.
For example, consider the following two options:
When specifying 1 or more argument values for -AlphaList, PowerArgs recognizes that the argument value list terminates at the next option, -BetaFlag:
Those all work as desired: -BetaFlag appears to be recognized as a terminator for the preceding option's parameter list.
However, when there are 0 argument values for -AlphaList, PowerArgs fails to recognize -BetaFlag as a terminator:
In this case, the string "-BetaFlag" is interpreted as an argument value of -AlphaList. This is undesirable behavior: it is inconsistent with the behavior above, and typically causes the application to fail out.
The behavior we'd like to see is:
This should assign AlphaList to a List instance that contains no items (i.e. is empty).
There are two workarounds, but we don't find these friendly:
It's unfriendly to end users to expect them to know these, or to try to explain it to them in the command help. The second workaround also prevents multiple empty list options from being specified: only one option can be at the end of the command line, so other list options would require the first workaround as well.
The text was updated successfully, but these errors were encountered: