Simplified Where-Object for multiple conditions on the same property for PowerShell? →
[](https://powershellone.files.wordpress.com/2015/10/3107494832_60009ec22b_m.jpg)
While PowerShell version 3 already introduced a (quite controversial) simplified syntax for the Where-Object cmdlet (alias where). It still doesn’t account for a quite common error PowerShell beginners encounter when using where with multiple conditions on the same property. As an example let’s say we would like to filter the range 1-10 to get only those numbers that are between 6 and 7. I’ve seen many people (yes that includes me) attempting to do it like below since it seems a logical translation of ‘where x is greater than 5 and lower than 8’.:
[code language=”powershell”]
1..10 | where {$ -gt 5 -and -lt 8}
#correct version
1..10 | where {$_ -gt 5 -and $_ -lt 8}
[/code]
Granted that this failing makes mathematically total sense since it should say ‘where x is greater 5 than and x is lower than 8’ . I’d wish there would be a syntax supporting something like this:
[code language=”powershell”]
1..10 | where {$_ (-gt 5 -and -lt 8)}
#or
Get-Process | where {$_.Name (-like ‘power’ -and -notlike ‘ise’)}
[/code]
The idea is that the parentheses would indicate that the preceding variable should be considered as the (left-hand) parameter for the operator. I came up with a crude proof of concept on how this could be done:
https://gist.github.com/d24442b2bbb72f5ff269
What do you think, would you also like to see this kind of syntax for Where-Object?
Review of methods to download files using PowerShell →
The goal of this post is to review and compare different methods to download files using PowerShell. As part of the review I would like to share (in addition to the inline source code you can also download a module (Get-FileMethods) that contains all functions via GitHub) some wrapper functions that follow the same pattern:
Show-CommandGUI an enhanced Show-Command for PowerShell →
After my last post (PowerShell tricks - Use Show-Command to add a simple GUI to your functions). I was thinking how one could write a function that would not have the deficiencies that Show-Command has when it comes to providing a GUI for functions. In addition to what Show-Command does I wanted a function that:
PowerShell tricks - Use Show-Command to add a simple GUI to your functions →
The Show-Command cmdlet has been introduced in PowerShell Version 3 and is very useful to help discovering and learning more about PowerShell cmdlets and their respective parameters (also built into the ISE as the Show-Command Add-on).:
[code language=”powershell”]
#Discover commands by running Show-Command without parameters
Show-Command
#Run Show-Command for a specific cmdlet
Show-Command Get-ChildItem
[/code]
Show-Command can be also utilized for your own functions in order to provide your users with a simple GUI as it builds a graphical user interface for the provided function on the fly. Show-Command displays:
PowerShell tricks – Useful default parameters to add to your profile →
Since version 3 PowerShell introduced $PSDefaultParameterValues which is a built-in preference variable which lets you specify default values for any cmdlet or advanced function. You can read much more about it inside the respective help file. In a nutshell $PSDefaultParameterValues is a hash-table where (in its most common version) the key consists of the cmdlet name and parameter name separated by a colon (:) and the value is the custom default value:
[code language=”powershell”]
Expanding aliases in PowerShell ISE or any PowerShell file →
Further extending my PowerShell ISE module (ISEUtils) I’ve added a function to convert aliases either in the currently active ISE file or (in case a a path is provided) within any PowerShell file (that way the function can be also used from the PowerShell Console) to their respective definitions.
Aliases are very useful when working interactively, since they help saving extra keystrokes when you just want to get things done fast. At the same time if we are speaking about production code where readability, and easy comprehension of the code are much more important the usage of aliases should be avoided ( read here for a good article on best practices for PowerShell alias usage).
With the Expand-Alias function you can get the best of both worlds. Writing clearer code while avoiding extraneous keystrokes. For the code samples in my blog posts I’m also using aliases quite a lot, but would like to start using the new function from now on.
Below is the source code for Expand-Alias:
https://gist.github.com/9db6632423d673ff18f6
Usage:
PowerShell tricks - Using dot(s) to refer to the current location →
Most people are aware that PowerShell supports commandline navigation in the same way as the good old command prompt (see my previous post Improve PowerShell commandline navigation for ways to enhance this):
[code language=”powershell”]
cd $env:USERPROFILE\Desktop
Resolve-Path ‘.’
#change to the current direction (doing nothing)
cd .
#move up one level
Resolve-Path ‘..’
cd ..
[/code]
The above is using cd as the alias for the Set-Location Cmdlet providing:
Create an integrated (WPF based) ISE Add-On with PowerShell →
Using Microsoft SyncToy through PowerShell →
This post is about running Microsoft SyncToy via PowerShell. For those that don’t know SyncToy:
Using the String.Split method with multiple separator characters in PowerShell →
This post is about what I thought of an odd behaviour when calling the .NET String.Split method with multiple separator characters from PowerShell. I first came across this myself but didn’t really pay much attention to it. Only after reading about it again over on Tommy Maynard’s blog, I decided to find out more.
Let’s have a look at an example first:
[code language=”powershell”]
#using String.Split with one separator character works as expected
‘This is a test’.Split(‘e’)
#using multiple characters not so much
‘c:\test’.Split(‘\’)
‘c:\test’.Split(‘\’).Count
[/code]
When running the second example trying to split a string based on double backslashes the result is an array of 3 strings instead of two. Let’s try to see why this is happening by retrieving the specific overload definition we are using:
[code language=”powershell”]
#get the overload definition of the method we are using
‘‘.Split.OverloadDefinitions[0]
#string[] Split(Params char[] separator)
[/code]
Ok, it looks like this overload of the Split method expects a character array for the separator parameter. That is why we saw an additional split, every character of the string argument ‘\’ is considered as a unique separator. Let’s see if String.Split has other overload definitions that accept a String as the separator argument:
[code language=”powershell”]
‘‘.Split.OverloadDefinitions | Select-String ‘string[] separator’ -SimpleMatch
<#
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)
#>
[/code]
Indeed, there are two overloads that accept a String array argument instead. Let’s use the first one. We don’t need the StringSplitOptions parameter in this case and can therefore use a value of ‘None’ for the argument.
[code language=”powershell”]
#this doesn’t work since we need a String array
‘c:\test’.Split(‘\’, ‘None’)
#finally we get only two parts back
‘c:\test’.Split(@(‘\’), ‘None’)
‘c:\test’.Split(@(‘\’), ‘None’).Count
[/code]
We could have used the -split operator in the first place, but that would have been to easy, right ;-). Furthermore with the String.Split method we can also split a string by multiple strings in just one go:
[code language=”powershell”]
#using -split operator we need to escape the \ by doubling them since we are dealing with regular expressions
‘c:\test’ -split ‘\\’
#splitting by two strings
‘split by xx and yy in one go’.Split((‘xx’,’yy’),’None’)
#can be done also with -split using a scriptBlock