Category: PowerShell

Windows PowerShell Tips From Microsoft TechNet Windows PowerShell Script Repository Getting Started With Windows PowerShell From Microsoft TechNet The Windows PowerShell Toolbox From TechNet Windows PowerShell Quick Reference

Today, I came across a weird behavior by PowerShell that it doesn’t validate the parameter names 🙁 Below is the sample code that explains the behavior i am speaking about: PS C:> type .Test-Commandline-Parameters.ps1 param([switch]$Debug) Write-Host $Debug PS C:> .Test-Commandline-Parameters.ps1 -debug True PS C:> .Test-Commandline-Parameters.ps1 -debugging False PS C:> .Test-Commandline-Parameters.ps1 -debu True PS C:> .Test-Commandline-Parameters.ps1 -de True PS C:> .Test-Commandline-Parameters.ps1 -d True PS C:> .Test-Commandline-Parameters.ps1 -debeg False PS C:> .Test-Commandline-Parameters.ps1 -deer False PS C:>   For more details read my article in MS PS TechNet Forums here.

Priority handling when there are conflicting and/or same variables at both Machine and User level: PS C:> $a = [Environment]::GetEnvironmentVariable("Temp","Machine") PS C:> echo $a C:WindowsTEMP PS C:> $a = [Environment]::GetEnvironmentVariable("Temp","User") PS C:> echo $a C:UsersgovardhanAppDataLocalTemp PS C:> $a = [Environment]::GetEnvironmentVariable("Temp") PS C:> echo $a C:UsersGOVARD~1AppDataLocalTemp PS C:> In case of a conflict, Windows and thus PS refers to User level variable under a user session.   The weird behavior is sometimes, you environment variables aren’t read as either type “User” or “Machine” but can be read without any type specification. PS C:> $a = [Environment]::GetEnvironmentVariable("appdata","User") PS C:> echo $a PS […]