Normally, if you want to defer the specification of a switch parameter to some variable, you can pass an expression to the switch parameter, as seen with the WhatIf parameter.
test.ps1
param ( [string] $source, [string] $dest, [switch] $test )
Copy-Item -Path $source -Destination $dest -WhatIf:$test
This allows you great flexibility when working with switches. However, when you call powershell with cmd.exe or something, you wind up with something like this:
D:\test>powershell -file test.ps1 -source test.ps1 -dest test.copy.ps1 -test:$true
D:\test\test.ps1 : Cannot process argument transformation on
parameter 'test'. Cannot convert value "System.String" to type "System.Manageme
nt.Automation.SwitchParameter", parameters of this type only accept booleans or
numbers, use $true, $false, 1 or 0 instead.
At line:0 char:1
+ <<<<
+ CategoryInfo : InvalidData: (:) [test.ps1], ParentContainsError
RecordException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,test.ps1
However, the same result appears when passing -test:true
, and -test:1
. Why doesn't this work? Shouldn't Powershell's type conversion system automatically recognize these strings as being convertible to bool or switch, and convert them?
Does this mean that when calling powershell scripts from some other system (such as a build system) it's necessary to construct complex flow control structures to determine whether or not to include a switch in the command string, or omit it? This seems tedious and error prone, which leads me to believe it's not the case.