Set to true nullable bool arguments without the value

[KvanTTT]

Consider the following class:

class Parameters
{
    [Option("bool")]
    public bool Bool { get; set; }
    
    [Option("nullable-bool")]
    public bool? NullableBool { get; set; }
}

It works fine for such arguments: --bool --nullable-bool true but doesn't work for --bool --nullable-bool.

I suggest making it working for nullable bool types.

[moh-hassan]

I think that no need for nullable bool arguments because you can set the default value in option (true/false) The nullable bool is undefined value (have three state undefined/true/false)

Without passing the parameter, you get the default value true or false With passing the parameter you get true value see my answer and demo case

[markdulfer]

I have a scenario where default settings are pulled from a database, but I want the ability to override certain settings with a commandline switch. In this case, I actually do want a nullable bool for flags. If the switch is not passed on the commandline (hence value = null) then use the default that came from the database, otherwise override with the commandline switch.

[moh-hassan]

If the switch is not passed on the commandline (hence value = null)

Can we suppose this scenario

If the switch is not passed on the commandline (hence value = false)

Flags as the standard in linux/unix and window Environment is an option of boolean type, and is always false by default (e.g. --verbose, --quiet, --all) When passed in the commandline it becomes true No third state (null/undefined values) is permitted.

How to Apply your scenario

I want the ability to override certain settings with a commandline switch.

1. You need not to set the default value for all boolean options and not using nullable bool?, e.g.

        //no Default, to have all control of the option, not bool?
   [Option('n',"navgation",HelpText = "navigate.")]
       public bool  Navigation { get; set; }
   

2. Then you can validate the options based on the values coming from database and overwrite it. You can validate you data after parsing, like this

     var  result = Parser.Default.ParseArguments<Options>(args);
     var options = (result as Parsed<Options>).Value;
     if (options != null)
       { 	
    	 //do all validation , read from database ,set the corresponding value of the options
    	 //If the switch is not passed on the commandline (hence value = false) then use the default that came from the database
    	 //example
    	 if (!options.Navigation)  //it's flase, i.e. not passed on the commandline
    			options.Navigation =true;
   
    	}
   
    	//proceed with processing with the new values of options
    	result.MapResult (......)
   

In this way you have all the control over the boolean values without nullable bool?

[DaEgi01]

same issue, same usecase.

@moh-hassan that solution does not work. since if I want to explicitly override a default value that is true with a false value, it can't be handled properly. you just can't differentiate between the "don't want to override" and a "want to override with false" intent.

Flags as the standard in linux/unix and window Environment is an option of boolean type, and is always false by default (e.g. --verbose, --quiet, --all)

if its a bool? its not a flag anymore.

[KvanTTT]

Finally, I've developed own light cli processor with such feature support, see CliParametersParser

[tig]

I'm with @KvanTT on this. I want nullable support for bools. I want an option flag to be able to override a setting that is independent of command-line invocation. Example: My app prints. Users can set landscape/portrait orientation in Windows' printer settings.

    [Option('l', "landscape", Required = false, HelpText = "Print in landscape mode.")]
    public bool? Landscape { get; set; }

    [Option('p', "printer", Default = "", HelpText = "Printer name to print to.")]
    public string Printer { get; set; }

The customer should NOT have to specify a command line flag for landscape if they've already set the printer up for landscape mode.

winprint -p "Laserjet in landscape mode" file.txt

Without bool? support, the line above will surprise the user because it will set Landscape == false.

[moh-hassan]

@tig Do you mean to use nullable bool Landscape as scalar token like:

landscape true
OR
landscape false

//scalar token should have a value
Edit: Currently it's working in this way, but you can't use landscape without value.

[mansellan]

Similar use-case. I want to allow --verbose or --quiet, but in my case, command line args are just one possible source for this (another is saved configuration). So I'd like it to be able to infer that for bool?, it will accept:

1. --{option} => true
2. --{option}=true|false => value
3. (omitted) => null

2 and 3 work just fine, but command-line users are used to using 1 for quickly switching things on, and I'd like to accomodate that.

[Kira-NT]

It's a total lame that there's no such feature...

[detoxhby]

up

[aaronenberg]

@moh-hassan Please introduce support for Option 1. suggested by @mansellan

[Kira-NT]

@aaronenberg, as I said in my PR that implements this feature, it's not gonna happen. Forget about this legacy, and embrace something clean and fresh - dotnet/command-line-api.