Something is really weird with this language. I'm trying to execute a function and use its result value as condition. This is my code:
function Get-Platform()
{
# Determine current Windows architecture (32/64 bit)
if ([System.Environment]::GetEnvironmentVariable("ProgramFiles(x86)") -ne $null)
{
echo "x64"
return "x64"
}
else
{
echo "x86"
return "x86"
}
}
if (Get-Platform -eq "x64")
{
echo "64 bit platform"
}
if (Get-Platform -eq "x86")
{
echo "32 bit platform"
}
The expected output is this:
x64
64 bit platform
But the actual output is this:
64 bit platform
32 bit platform
What's going on here? How can this be fixed? I couldn't find any examples on the web that use functions inside an ifcondition. Is that possible at all in Powershell? I'm on Windows 7 with no special setup, so I have whatever PS version comes with it.
If you want to compare the return value of a function in a conditional, you must group the function call (i.e. put it in parentheses) or (as #FlorianGerhardt suggested) assign the return value of the function to a variable and use that variable in the conditional. Otherwise the comparison operator and the other operand would be passed as arguments to the function (where in your case they're silently discarded). Your function then returns a result that is neither "" nor 0 nor $null, so it evaluates to $true, causing both messages to be displayed.
This should do what you want:
...
if ( (Get-Platform) -eq 'x64' ) {
echo "64 bit platform"
}
...
BTW, you should avoid using separate if statements for conditions that are mutually exclusive. For a platform check an if..then..elseif
$platform = Get-Platform
if ($platform -eq "x64") {
...
} elseif ($platform -eq "x86") {
...
}
or a switch statement
Switch (Get-Platform) {
"x86" { ... }
"x64" { ... }
}
would be more appropriate.
I'd also avoid echoing inside the function. Just return the value and do any echoing that might be required in with the returned value. Anything echoed inside the function will also be returned to the caller.
One last note: personally I'd rather not rely on the existence of a particular folder or environment variable for determining the operating system architecture. Using WMI for this task deems me a lot more reliable:
function Get-Platform {
return (gwmi Win32_OperatingSystem).OSArchitecture
}
This function will return a string "32-Bit" or "64-Bit", depending on the operating system architecture.
I think you are comparing a function and not the function result. Also somehow the echo does not work as expected in a function. I usually use Write-Host.
Here is my solution to your problem:
function Get-Platform()
{
# Determine current Windows architecture (32/64 bit)
if ([System.Environment]::GetEnvironmentVariable("ProgramFiles(x86)") -ne $null)
{
Write-Host("x64")
return "x64"
}
else
{
Write-Host("x86")
return "x86"
}
}
$platform = Get-Platform
if ($platform -eq 'x64')
{
echo "64 bit platform"
}
if ($platform -eq 'x86')
{
echo "32 bit platform"
}
Related
Something is really weird with this language. I'm trying to execute a function and use its result value as condition. This is my code:
function Get-Platform()
{
# Determine current Windows architecture (32/64 bit)
if ([System.Environment]::GetEnvironmentVariable("ProgramFiles(x86)") -ne $null)
{
echo "x64"
return "x64"
}
else
{
echo "x86"
return "x86"
}
}
if (Get-Platform -eq "x64")
{
echo "64 bit platform"
}
if (Get-Platform -eq "x86")
{
echo "32 bit platform"
}
The expected output is this:
x64
64 bit platform
But the actual output is this:
64 bit platform
32 bit platform
What's going on here? How can this be fixed? I couldn't find any examples on the web that use functions inside an ifcondition. Is that possible at all in Powershell? I'm on Windows 7 with no special setup, so I have whatever PS version comes with it.
If you want to compare the return value of a function in a conditional, you must group the function call (i.e. put it in parentheses) or (as #FlorianGerhardt suggested) assign the return value of the function to a variable and use that variable in the conditional. Otherwise the comparison operator and the other operand would be passed as arguments to the function (where in your case they're silently discarded). Your function then returns a result that is neither "" nor 0 nor $null, so it evaluates to $true, causing both messages to be displayed.
This should do what you want:
...
if ( (Get-Platform) -eq 'x64' ) {
echo "64 bit platform"
}
...
BTW, you should avoid using separate if statements for conditions that are mutually exclusive. For a platform check an if..then..elseif
$platform = Get-Platform
if ($platform -eq "x64") {
...
} elseif ($platform -eq "x86") {
...
}
or a switch statement
Switch (Get-Platform) {
"x86" { ... }
"x64" { ... }
}
would be more appropriate.
I'd also avoid echoing inside the function. Just return the value and do any echoing that might be required in with the returned value. Anything echoed inside the function will also be returned to the caller.
One last note: personally I'd rather not rely on the existence of a particular folder or environment variable for determining the operating system architecture. Using WMI for this task deems me a lot more reliable:
function Get-Platform {
return (gwmi Win32_OperatingSystem).OSArchitecture
}
This function will return a string "32-Bit" or "64-Bit", depending on the operating system architecture.
I think you are comparing a function and not the function result. Also somehow the echo does not work as expected in a function. I usually use Write-Host.
Here is my solution to your problem:
function Get-Platform()
{
# Determine current Windows architecture (32/64 bit)
if ([System.Environment]::GetEnvironmentVariable("ProgramFiles(x86)") -ne $null)
{
Write-Host("x64")
return "x64"
}
else
{
Write-Host("x86")
return "x86"
}
}
$platform = Get-Platform
if ($platform -eq 'x64')
{
echo "64 bit platform"
}
if ($platform -eq 'x86')
{
echo "32 bit platform"
}
Forgive me as I'm still learning powershell so this might be a silly question, but how do I add an options to a .ps1?
For example, I have currently have a script that downloads a file and runs it, but if it cant run it, it will look for the file locally and run it then. How do I separate these two so the user can pick either to download or just run locally?
e.g.:
'./script.ps1 local '
Will look for the file locally and run it
'./script.ps1 external'
will download the file and run it
I'm not sure if functions will be appropriate for this because the point of the script isn't to import it into the modules, I just want it so you run the .ps1.
At the top of your file add;
Param(
[Parameter(Position=1)][string]$option
)
Switch ($option)
{
'local' { RunLocal }
'other' { RunOther }
default { RunDefault }
}
Would look something like
Param(
[Parameter(Position=1)][string]$option
)
function RunLocal {
Write-Host "RunLocal"
}
function RunOther {
Write-Host "RunOther"
}
function RunDefault {
Write-Host "RunDefault"
}
Switch ($option)
{
'local' { RunLocal }
'other' { RunOther }
default { RunDefault }
}
If you need to constrain the values passed to a parameter to a fixed set of values, use the [ValidateSet(...)] parameter attribute:
[CmdletBinding()]
Param(
[ValidateSet('Local', 'External')]
[string] $Option = 'Local'
)
Switch ($Option)
{
'local' {
# ...
break
}
'external' {
# ...
break
}
}
The above defaults -Option (and thus parameter variable $Option) to 'Local', while allowing to pass either Local or External explicitly to -Option - no other values are permitted.
I have a fairly large powershell scripts with many (20+) functions which perform various actions.
Right now all of the code doesn't really have any error handling or retry functionality. If a particular task/function fails it just fails and continues on.
I would like to improve error handling and implement retries to make it more robust.
I was thinking something similar to this:
$tries = 0
while ($tries -lt 5) {
try{
# Do Something
# No retries necessary
$tries = 5;
} catch {
# Report the error
# Other error handling
}
}
The problem is that I have many many steps where I would need to do this.
I don't think it make sense to implement the above code 20 times. That seems really superfluous.
I was thinking about writing an "TryCatch" function with a single parameter that contains the actual function I want to call?
I'm not sure that's the right approach either though. Won't I end up with a script that reads something like:
TryCatch "Function1 Parameter1 Parameter2"
TryCatch "Function2 Parameter1 Parameter2"
TryCatch "Function3 Parameter1 Parameter2"
Is there a better way to do this?
If you frequently need code that retries an action a number of times you could wrap your looped try..catch in a function and pass the command in a scriptblock:
function Retry-Command {
[CmdletBinding()]
Param(
[Parameter(Position=0, Mandatory=$true)]
[scriptblock]$ScriptBlock,
[Parameter(Position=1, Mandatory=$false)]
[int]$Maximum = 5,
[Parameter(Position=2, Mandatory=$false)]
[int]$Delay = 100
)
Begin {
$cnt = 0
}
Process {
do {
$cnt++
try {
# If you want messages from the ScriptBlock
# Invoke-Command -Command $ScriptBlock
# Otherwise use this command which won't display underlying script messages
$ScriptBlock.Invoke()
return
} catch {
Write-Error $_.Exception.InnerException.Message -ErrorAction Continue
Start-Sleep -Milliseconds $Delay
}
} while ($cnt -lt $Maximum)
# Throw an error after $Maximum unsuccessful invocations. Doesn't need
# a condition, since the function returns upon successful invocation.
throw 'Execution failed.'
}
}
Invoke the function like this (default is 5 retries):
Retry-Command -ScriptBlock {
# do something
}
or like this (if you need a different amount of retries in some cases):
Retry-Command -ScriptBlock {
# do something
} -Maximum 10
The function could be further improved e.g. by making script termination after $Maximum failed attempts configurable with another parameter, so that you can have have actions that will cause the script to stop when they fail, as well as actions whose failures can be ignored.
I adapted #Victor's answer and added:
parameter for retries
ErrorAction set and restore (or else exceptions do not get caught)
exponential backoff delay (I know the OP didn't ask for this, but I use it)
got rid of VSCode warnings (i.e. replaced sleep with Start-Sleep)
# [Solution with passing a delegate into a function instead of script block](https://stackoverflow.com/a/47712807/)
function Retry()
{
param(
[Parameter(Mandatory=$true)][Action]$action,
[Parameter(Mandatory=$false)][int]$maxAttempts = 3
)
$attempts=1
$ErrorActionPreferenceToRestore = $ErrorActionPreference
$ErrorActionPreference = "Stop"
do
{
try
{
$action.Invoke();
break;
}
catch [Exception]
{
Write-Host $_.Exception.Message
}
# exponential backoff delay
$attempts++
if ($attempts -le $maxAttempts) {
$retryDelaySeconds = [math]::Pow(2, $attempts)
$retryDelaySeconds = $retryDelaySeconds - 1 # Exponential Backoff Max == (2^n)-1
Write-Host("Action failed. Waiting " + $retryDelaySeconds + " seconds before attempt " + $attempts + " of " + $maxAttempts + ".")
Start-Sleep $retryDelaySeconds
}
else {
$ErrorActionPreference = $ErrorActionPreferenceToRestore
Write-Error $_.Exception.Message
}
} while ($attempts -le $maxAttempts)
$ErrorActionPreference = $ErrorActionPreferenceToRestore
}
# function MyFunction($inputArg)
# {
# Throw $inputArg
# }
# #Example of a call:
# Retry({MyFunction "Oh no! It happened again!"})
# Retry {MyFunction "Oh no! It happened again!"} -maxAttempts 10
Solution with passing a delegate into a function instead of script block:
function Retry([Action]$action)
{
$attempts=3
$sleepInSeconds=5
do
{
try
{
$action.Invoke();
break;
}
catch [Exception]
{
Write-Host $_.Exception.Message
}
$attempts--
if ($attempts -gt 0) { sleep $sleepInSeconds }
} while ($attempts -gt 0)
}
function MyFunction($inputArg)
{
Throw $inputArg
}
#Example of a call:
Retry({MyFunction "Oh no! It happend again!"})
Error handling is always going to add more to your script since it usually has to handle many different things. A Try Catch function would probably work best for what you are describing above if you want to have each function have multiple tries. A custom function would allow you to even set things like a sleep timer between tries by passing in a value each time, or to vary how many tries the function will attempt.
I am trying to write a simple wrapper that accept one parameter for the output.
This is how it looks now
function Get-data{
param (
[switch]$network,
[switch]$profile,
[switch]$server,
[switch]$devicebay
)
if ($network.IsPresent) { $item = "network"}
elseif ($profile.IsPresent) {$item = "profile"}
elseif ($server.IsPresent) {$item = "server"}
elseif ($devicebay.IsPresent){$item = "devicebay"}
$command = "show $item -output=script2"
}
Clearly this could be optimize but I am struggling to wrap my head around on how I can achieve it .Is there some easy way to ensure only single parameter is accepted and used without resorting to multiple elseif statements?
Also I would like to provide array of paramters instead doing it the way it is done at the moment.
Another thing you could do instead of all those switch parameters is to use a [ValidateSet]
function Get-Data{
[cmdletbinding()]
param(
[Parameter(Mandatory=$true)]
[ValidateSet('Network','Profile','Server','DeviceBay')]
[string]$Item
)
Switch ($Item){
'network' {'Do network stuff'}
'profile' {'Do profile stuff'}
'server' {'Do server stuff'}
'devicebay' {'Do devicebay stuff'}
}
}
Probably not the most elegant solution, but using parametersets makes powershell do some of the work for you:
#requires -version 2.0
function Get-data {
[cmdletbinding()]
param(
[parameter(parametersetname="network")]
[switch]$network,
[parameter(parametersetname="profile")]
[switch]$profile,
[parameter(parametersetname="server")]
[switch]$server,
[parameter(parametersetname="devicebay")]
[switch]$devicebay
)
$item = $PsCmdlet.ParameterSetName
$command = "show $item -output=script2"
}
This example will error out if you don't provide one of the switches, but you could probably provide an extra switch that does nothing or errors more gracefully if you want to account for that case...
You can add the [cmdletbinding()] keyword so you get $PSBoundParameters, and use that for a switch pipeline:
function Get-data{
[cmdletbinding()]
param (
[switch]$network,
[switch]$profile,
[switch]$server,
[switch]$devicebay
)
Switch ($PSBoundParameters.GetEnumerator().
Where({$_.Value -eq $true}).Key)
{
'network' { 'Do network stuff' }
'profile' { 'Do profile stuff' }
'server' { 'Do server stuff' }
'devicebay' { 'Do devicebay stuff' }
}
}
Since you want only one switch to be enabled, an enum might help you.
This way, you're not using a switch but a standard parameter - still, the user of the cmdlet can use TAB to autocomplete the values that may be entered.
Just set the type of the parameter to your enum.
Suppose I run msbuild like this:
function Clean-Sln {
param($sln)
MSBuild.exe $sln /target:Clean
}
Clean-Sln c:\temp\SO.sln
In Posh console the output is in colors. That's pretty handy - you spot colors just by watching the output. And e.g. not important messages are grey.
Question
I'd like to add ability to redirect it somewhere like this (simplified example):
function Clean-Sln {
param($sln)
MSBuild.exe $sln /target:Clean | Redirect-AccordingToRedirectionVariable
}
$global:Redirection = 'Console'
Clean-Sln c:\temp\SO.sln
$global:Redirection = 'TempFile'
Clean-Sln c:\temp\Another.sln
If I use 'Console', the cmdlet/function Redirect-AccordingToRedirectionVariable should output the msbuild messages with colors the same way as the output was not piped. In other words - it should leave the output as it is.
If I use 'TempFile', Redirect-AccordingToRedirectionVariable will store the output in a temp file.
Is it even possible? I guess it is not :|
Or do you have any advice how to achieve the goal?
Possible solution:
if ($Redirection -eq 'Console) {
MSBuild.exe $sln /target:Clean | Redirect-AccordingToRedirectionVariable
} else {
MSBuild.exe $sln /target:Clean | Out-File c:\temp.txt
}
But if you imagine there can be many many msbuild calls, it's not ideal.
Don't be shy to tell me any new suggestion how to cope with it ;)
Any background info about redirections/coloring/outpu is welcome as well.
(The problem is not msbuild specific, the problem touches any application that writes colored output)
Yeah I would avoid piping colored output. At that point, AFAICT, all color info is lost.
I would recommend using the /filelogger and /noconsolelogger parameters on MSBuild e.g.:
function Invoke-MSBuild($project, [string[]]$targets, [switch]$logToFile) {
$OFS = ';'
$targetArg = if ($targets) {"/t:$targets"} else {''}
if ($logToFile) {
msbuild.exe $project $targetArg /filelogger /noconsolelogger
}
else {
msbuild.exe $project $targetArg
}
}
or you could do something even simpler like this:
function Invoke-MSBuild($project, [string[]]$targets, $logFile) {
$OFS = ';'
$targetArg = if ($targets) {"/t:$targets"} else {''}
if ($logFile) {
msbuild.exe $project $targetArg > $logFile
}
else {
msbuild.exe $project $targetArg
}
}