Implement --no-SOME_OPTION

[CanuckGamer]

I want these mutually exclusive options:

• --updateParts
• --not-updateParts

The default is to update parts, and it's disabled if the second flag is passed. The user needs to pass one flag or the other (so they don't get a behavior they didn't explicitly ask for).

Is there any way to do this? I had a go with this:

`class Options { private static bool _updateParts;

public Options(bool updateParts, bool doNotUpdateParts)
{
	_updateParts = updateParts;
	if (doNotUpdateParts) _updateParts = false;
}

[Option('c', "updateParts", SetName = "update", Required = true, Default = true)]
public static bool UpdateParts { get { return _updateParts; } }

[Option('C', "no-updateParts", SetName = "noUpdate", Required = true, Default = false)]
public static bool DoNotUpdateParts { get { return !_updateParts; } }

}`

Generally speaking this works, but it means I can't add two other options which are mutually exclusive. Imagine I now want to add:

• --doLogging
• --not-doLogging

I can't make them mutually exclusive because they don't belong to either set update or noUpdate.

[mhbarnes]

The default is to update parts, and it's disabled if the second flag is passed. The user needs to pass one flag or the other (so they don't get a behavior they didn't explicitly ask for).

If the user has to pass a flag to avoid unintentional behavior, why is there a default behavior? If --updateParts is the default, then a flag specifying that option is unnecessary.

Is there a reason why you can't just use 1 of the flags? If the default behavior is to update the parts, you could just have the --not-updateParts flag to disable part updating if needed.

[CanuckGamer]

What if you don't want a default behavior, and the user must specify if he wants to do x or y, but not both, and not neither.

On Tue., Nov. 2, 2021, 5:01 p.m. Michael Barnes, @.***> wrote:

The default is to update parts, and it's disabled if the second flag is passed. The user needs to pass one flag or the other (so they don't get a behavior they didn't explicitly ask for).

If the user has to pass a flag to avoid unintentional behavior, why is there a default behavior? If --updateParts is the default, then a flag specifying that option is unnecessary.

Is there a reason why you can't just use 1 of the flags? If the default behavior is to update the parts, you could just have the --not-updateParts flag to disable part updating if needed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/commandlineparser/commandline/issues/783#issuecomment-958162893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7BDBXUQNUGNCOXAUW5IETUKBNSXANCNFSM5GCBUKHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[mhbarnes]

That isn't typically how options in command lines work (e.g. a --debug option is off by default unless specified).

If the implementation cannot be budged, you can use a string option and check for the contents:

public class Options
{
    [Option("updateParts",
    	Required = true)]
    public string UpdateParts { get; set; }
}

static void Main(string[] args)
{
    CommandLine.Parser.Default.ParseArguments(args)
    .WithParsed<Options>(opts =>
    {
        bool updateParts;
        if (opts.UpdateParts.ToLower() == "on")
        {
        	updateParts = true;
        }
        else if (opts.UpdateParts.ToLower() == "off")
        {
	        updateParts = false;
        }
        else
        {
    	    // handle if invalid input shouldn't be accepted 
        }
    });
}

You might also be able to use an Enum option to reduce the amount of input handling, but you'll have to experiment with that.