I have to invoke a PowerShell script from a batch file. One of the arguments to the script is a boolean value:
C:\\Windows\\System32\\WindowsPowerShell\\v1.0
In PowerShell, boolean parameters can be declared by mentioning their type before their variable.
function GetWeb() {
param([bool] $includeTags)
........
........
}
You can assign value by passing $true | $false
GetWeb -includeTags $true
To summarize and complement the existing answers, as of Windows PowerShell v5.1 / PowerShell Core 7.0.0-preview.4:
David Mohundro's answer rightfully points that instead of [bool]
parameters you should use [switch] parameters in PowerShell, where the presence vs. absence of the switch name (-Unify
specified vs. not specified) implies its value, which makes the original problem go away.
However, on occasion you may still need to pass the switch value explicitly, particularly if you're constructing a command line programmatically:
In PowerShell Core, the original problem (described in Emperor XLII's answer) has been fixed.
That is, to pass $true
explicitly to a [switch]
parameter named -Unify
you can now write:
pwsh -File .\RunScript.ps1 -Unify:$true # !! ":" separates name and value, no space
The following values can be used: $false
, false
, $true
, true
, but note that passing 0
or 1
does not work.
Note how the switch name is separated from the value with :
and there must be no whitespace between the two.
Note: If you declare a [bool]
parameter instead of a [switch]
(which you generally shouldn't), you must use the same syntax; even though -Unify $false
should work, it currently doesn't - see this GitHub issue.
In Windows PowerShell, the original problem persists, and - given that Windows PowerShell is no longer actively developed - is unlikely to get fixed.
The workaround suggested in LarsWA's answer - even though it is based on the official help topic as of this writing - does not work in v5.1
Using -Command
instead of -File
is the only effective workaround:
:: # From cmd.exe
powershell -Command "& .\RunScript.ps1 -Unify:$true"
With -Command
you're effectively passing a piece of PowerShell code, which is then evaluated as usual - and inside PowerShell passing $true
and $false
works (but not true
and false
, as now also accepted with -File
).
Caveats:
Using -Command
can result in additional interpretation of your arguments, such as if they contain $
chars. (with -File
, arguments are literals).
Using -Command
can result in a different exit code.
For details, see this answer and this answer.
I think, best way to use/set boolean value as parameter is to use in your PS script it like this:
Param(
[Parameter(Mandatory=$false)][ValidateSet("true", "false")][string]$deployApp="false"
)
$deployAppBool = $false
switch($deployPmCmParse.ToLower()) {
"true" { $deployAppBool = $true }
default { $deployAppBool = $false }
}
So now you can use it like this:
.\myApp.ps1 -deployAppBool True
.\myApp.ps1 -deployAppBool TRUE
.\myApp.ps1 -deployAppBool true
.\myApp.ps1 -deployAppBool "true"
.\myApp.ps1 -deployAppBool false
#and etc...
So in arguments from cmd you can pass boolean value as simple string :).
I had something similar when passing a script to a function with invoke-command. I ran the command in single quotes instead of double quotes, because it then becomes a string literal. 'Set-Mailbox $sourceUser -LitigationHoldEnabled $false -ElcProcessingDisabled $true';
You can also use 0
for False
or 1
for True
. It actually suggests that in the error message:
Cannot process argument transformation on parameter 'Unify'. Cannot convert value
"System.String"
to type"System.Boolean"
, parameters of this type only accept booleans or numbers, use$true
,$false
, 1 or 0 instead.
For more info, check out this MSDN article on Boolean Values and Operators.
Try setting the type of your parameter to [bool]
:
param
(
[int]$Turn = 0
[bool]$Unity = $false
)
switch ($Unity)
{
$true { "That was true."; break }
default { "Whatever it was, it wasn't true."; break }
}
This example defaults $Unity
to $false
if no input is provided.
Usage
.\RunScript.ps1 -Turn 1 -Unity $false