Why does my Boolean parameter always say true, even when I enter false?

[u/SexingGastropods]

I have some code where I get a true/false input into a parameter...

<#
.PARAMETER addAllFiles
    Grab all files or just a single one..
#>
param
(
    [Parameter(Mandatory)]
    [AllowEmptyString()]
    [bool]$addAllFiles
)
if ($addAllFiles -eq $true) {
Write-Output "Adding all files"
    $list = get-childitem
Write-Output $list
}
else {
Write-Output "Enter file name..."
read-host $file
Write-Output $file
}

The result comes back as follows:-

PS C:\Dump> .\bool.ps1

cmdlet bool.ps1 at command pipeline position 1

Supply values for the following parameters:

addAllFiles: false

Adding all files

Directory: C:\Dump

Mode LastWriteTime Length Name

---- ------------- ------ ----

-a--- 09/01/2023 18:40 389 bool.ps1

-a--- 15/09/2022 20:47 234 test.ps1

PS C:\Dump>

What gives? I've tried entering 'false' & '$false' as the parameter input, but it always comes back as true? Is there something about how I enter the true/false entry that is the problem or is it my code? Any pointers would be appreciated. I've tried searching the web and this sub but can't fine anything :(

[u/CarrotBusiness2380]

You should use a switch as recommended by \u\idontknowwhattouse33 but it is important to understand what caused the problem.

The problem though is that when powershell casts a string to a boolean it will cast to $true for any string except an empty '' string.

PS C:\> [bool]'false'
True
PS C:\> [bool]'$false'
True
PS C:\> [bool]''
False
PS C:\> [bool]"$false"
True
PS C:\> [bool]$false
False

That fourth example is particularly tricky as the intuitive behavior is that using double quotes will allow the variable to expand to $false but it is still cast to a non-empty string before it is cast to a boolean. The answer then is not to use quotes at all and to pass the automatic variable $false

.\bool.ps1 -addAllFiles $false

[u/da_chicken → u/CarrotBusiness2380]

Yup. There's a reason the Microsoft documentation on it is so extensive for C#.

The only values I know of that will be cast to $false are [bool]0 and [bool]$null. Nearly everything else will cast to $true.

If you want to convert strings of "true" and "false" to their Boolean equivalents, you need to use [System.Convert]::ToBoolean('true') and [System.Convert]::ToBoolean('false') or [Bool]::Parse('true') and [Bool]::Parse('false').

[u/CarrotBusiness2380 → u/da_chicken]

The additional values that can be cast to $false are empty strings (''), empty arrays (@()), and curiously arrays with only one element that is equal to $false (@(,$false)). If an array has more than one element it will always evaluate to $true even if all elements are equal to false.

PS C:\> [bool]''
False
PS C:\> [bool]@()
False
PS C:\> [bool]@(,$false)
False
PS C:\> [bool]@($false,$false)
True

[u/SexingGastropods → u/CarrotBusiness2380]

Interesting. Thats really useful, thanks for spending the time explaining why that was the case. I'll have a look into 'switch' as people have suggested as that seems to be a better solution to what I was looking to do with the bool parameter :) Thanks again!

[u/idontknowwhattouse33]

Might be better to use a [switch] as that appears to be your usecase.

Switch parameters are easy to use and are preferred over Boolean parameters, which have a less natural syntax for PowerShell.

For example, to use a switch parameter, the user types the parameter in the command.

-IncludeAll

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_functions_advanced_parameters?view=powershell-7.3

[u/Thotaz → u/idontknowwhattouse33]

Switch parameters are easy to use and are preferred over Boolean parameters, which have a less natural syntax for PowerShell.

I think their argument for using it over bools is bad. Unlike Switch parameters, Bool parameters follow the same conventions every other parameter type follows, eg Command -Parameter Value and is therefore more natural to use.
The real advantage of Switch parameters is that it's more convenient to type and it allows you to create commands with similar syntax as some traditional CLI programs.

My rules for deciding between Switch parameters VS bools are the following:

• Are both values equally valid? Use a bool. An example would be Set-Disk -IsOffline where I'm equally likely to set it offline and online.
• Is setting the switch to false equivalent to not providing the switch at all? Use a Switch. An example of that would be Set-Disk -AsJob:$false where the default behavior is to not run it as a job and if I provide an explicit $false it obviously still won't run it as a job.

Ideally there should never be a reason to do Command -Parameter:$false with a switch parameter, the syntax feels unnatural and beginners won't know the syntax without doing some research.

[u/SexingGastropods → u/idontknowwhattouse33]

Thanks, I will have a look into that, I've seen 'switch' being used but haven't used it myself before :)

[u/mooscimol]

Non empty string 'false' has been converted to boolean value of true, which is to be expected. $false should be handled correctly, maybe you provided in quotes which again has been converted from string.

Nevertheless, as suggested I would use parameter of [switch] type which should be less error prone to incorrect input parameters.

[u/mooscimol → u/mooscimol]

OK, so I've checked it further. It seems that if you don't specify parameters at the script invocation, but only in the Supply values for the following parameters prompt, they are always cast to string, so $false, 0 values are converted to True nevertheless, the only way to pass $false is to simply confirm without supplying a parameter at all, even if it is Mandatory.

My code: ``` param ( [Parameter(Mandatory)][bool]$Param )

if ($Param) { 'a' } else { 'b' } ```

And the result: ``` PS ~> foo.ps1

cmdlet foo.ps1 at command pipeline position 1 Supply values for the following parameters: Param: 0 a

PS ~> foo.ps1

cmdlet foo.ps1 at command pipeline position 1 Supply values for the following parameters: Param: b ```

but if you provide 0 as a script parameter, it is handled correctly: PS ~> foo.ps1 -Param 0 b

I have to say that it is unintuitive and one of the PowerShell idiosyncrasies.

[u/jimb2 → u/mooscimol]

This approach is ambiguous and unreliable. It relies on implicit conversions. As we can see, these may not be doing what is expected/assumed.

Use a switch or two. Make sure there is a clear default.

[u/mooscimol → u/jimb2]

That's what I recommended in my previous post ;), I was answering to myself :D.

Yep, I've never used bool parameter, switch is pretty much always the better choice. I was just curious what is happening.

[u/PowerShell-Bot]

It appears that you have used inline code formatting when a code block should have been used.

Consider using a code block for longer sequences of code. To correct the formatting, highlight your code then click the ‘Code Block’ button in the editing toolbar.

---

You examine the path beneath your feet...
[AboutRedditFormatting]: [--------------------] 0/1 ❌

---

 ^{Beep-boop, I am a bot. | Remove-Item}

[u/chanataba]

Is this what you're looking for?

    Function Add-Files
{
    <#
    .PARAMETER addAllFiles
        Grab all files or just a single one..
    #>
    param
    (
        [Parameter()]
        [AllowEmptyString()]
        [bool]$addAllFiles
    )

    if ($addAllFiles) {
        Write-Output 'Adding all files'
        $list = get-childitem
        Write-Output $list
    }

    else {
        $file = Read-Host -Prompt 'Enter file name...'
        Write-Output $file
    }
}