Cleaning up text copied from eBooks into MS Word →

PowerShell Get-Command -Syntax output explained →

Find out in which version a PowerShell Cmdlet was introduced →

 Some days ago Thomas Rayner (whom I admire for his passion and consistency when it comes to sharing his knowledge) posted about the same topic on his blog. He mentioned a method on how to utilize GitHub in order to find out the earliest Version a PowerShell Cmdlet was introduced. When I read the Thomas’s post, I couldn’t resist thinking about an option to automate the process. My first attempt was to check whether the information is already part of the help system or could be retrieved using Get-Command (using ‘Expand-Archive’ as an example): [code language=”powershell”] Get-Command Expand-Archive | Format-List * | Out-String -Stream | Where-Object {$ -like ‘version’} Get-Help Expand-Archive -Full | fl * | Out-String -Stream | Where-Object {$_ -like ‘version’} [/code] While both commands return some information in relation to a version, in general, there is nothing telling us about the PowerShell version the Cmdlet was first introduced. The next thought I had, looking at Get-Help was the online version. [code language=”powershell”] Get-Help Expand-Archive -Online [/code] This command opens the default browser opening the HelpURI, which in this case looked like https://docs.microsoft.com/en-us/powershell/module/Microsoft.PowerShell.Archive/Expand-Archive?view=powershell-5.1. See the last part of the URI? There seemed to be some hope following this route. The webpage features a drop-down where users can select a PowerShell version (3-6). Selecting Version 3 from the drop-down for the Expand-Archive help page brought me to this URI https://docs.microsoft.com/en-us/powershell/module/Microsoft.PowerShell.Archive/Expand-Archive?view=powershell-6&viewFallbackFrom=powershell-3.0. Version 4 revealed a similar result, while the Version 5 URI did not contain the “viewFallback…” part. Similarly, when pasting a URI like https://docs.microsoft.com/en-us/powershell/module/Microsoft.PowerShell.Archive/Expand-Archive?view=powershell-3.0 into the browser’s address bar, it redirects automatically to the “viewFallback…” version. Great, there we have it, a pattern that can be automated :-):

Get .net Format Strings for given input →

Yet again, long time no post! .net Format Strings are very useful when it comes to taking control over the output of your scripts. e.g.: [code language=”powershell”] ‘{0:t}’ -f (Get-Date) #output: h:mm tt ‘{0:n1}’ -f 2.45 #output: 2.5 [/code] The problem with those Format Strings is, that hardly anyone can remember them. While there they are thoroughly documented and several nice folks have created cheat-sheets (e.g. here), I thought it would be nice to be able to get (at least the most common) Format Strings for a given input automatically along with the respective outputs within PowerShell. The function returns output for Integer, Double, and DateTime input. You can download Get-FormatStrings from my GithHub repository or just grab the code below: https://gist.github.com/25ec562a8bb21b1899044ca7913ae7ef

PowerShell tricks – Convert copied range from excel to an array of PSObjects →

In this post, I would like to share a simple function that converts tables copied from Excel to the clipboard into PowerShell objects. While there are several more efficient ways to retrieve data out of Excel files (e.g. COM, EPPlus), I sometimes just want something quick and dirty to get the job at hand done. https://gist.github.com/12f06bec82dc4cc93370b2fa7dc750f4 Usage:

Full text search using PowerShell, Everything, and Lucene →

Searching for files is something everyone does on a very regular basis. While Windows is consistently changing the way this is done with every new operating system, the built-in functionality is still far from being sufficient. Therefore, I’m always looking for methods on how to improve this (you can also find several blog posts in relation to file searches around here). In regards to searching for files based on file names or paths, I’m pretty happy with the performance of Everything. If it is about searching for files based on their content (aka full-text search), there is still room for improvement in my opinion. Recently I’ve been watching the session recordings from the PowerShell Conference Europe 2016 (I can highly recommend anyone that is interested in PowerShell to watch those).

Get help for Windows built-in command-line tools with PowerShell →

One of the reasons I like PowerShell is its built-in help system (here is a nice post in case you don’t know how to use PowerShell’s built-in help). E.g.: [code language=”powershell”] Get-Help Get-Command Get-Help Get-Command -Examples Get-Help Get-Command -Parameter Name [/code] In fact, once you get comfortable using PowerShell help aka Get-Help, you start missing similar built-in documentation for other tools/scripting languages. Wouldn’t it be nice if one could use Get-He.lp for Windows command-line tools?: [code language=”powershell”] Get-Help chkdsk Get-Help chkdsk -Examples Get-Help chkdsk -Paramater c [/code]

Reporting against Pester test results →

Pester is (for very good reasons) getting more and more popular. If you don’t know about Pester I would highly recommend you to start using it. Here are some good resources to learn about the framework:

PowerShell tricks – Open a dialog as topmost window →

Windows.Forms provides easy access to several built-in dialogs (see MSDN: Dialog-Box Controls and Components). Here is an usage example to show a “FolderBrowse” dialog: [code language=”powershell”] Add-Type -AssemblyName Windows.Forms $FolderBrowser = New-Object System.Windows.Forms.FolderBrowserDialog $FolderBrowser.Description = ‘Select the folder containing the data’ $result = $FolderBrowser.ShowDialog() if ($result -eq [Windows.Forms.DialogResult]::OK){ $FolderBrowser.SelectedPath } else { exit } [/code] While this works as expected, the dialog won’t show up as the topmost window. This could lead to situations where users of your script might miss the dialog or simply complain because they have to switch windows. Even though there is no built-in property to set the dialog as the topmost window, the same can be achieved using the second overload of the ShowDialog method (MSDN: ShowDialog method). This overload expects a parameter which indicates the parent windows of the dialog. Since the owning window will not be used after the dialog has been closed we can just create a new form on the fly within the method call: [code language=”powershell” highlight=”4”] Add-Type -AssemblyName System.Windows.Forms $FolderBrowser = New-Object System.Windows.Forms.FolderBrowserDialog $FolderBrowser.Description = ‘Select the folder containing the data’ $result = $FolderBrowser.ShowDialog((New-Object System.Windows.Forms.Form -Property @{TopMost = $true })) if ($result -eq [Windows.Forms.DialogResult]::OK){ $FolderBrowser.SelectedPath } else { exit } [/code]

PowerShell and XML part 1 - Visualize XPath expression →