I struggle with $myvar.foo vs. ($myvar).foo vs. ($myvar).foo() vs. $myvar.foo(); vs. $myvar.foo(1), etc., etc.

How do I know which one to use for which case? And then how to put this output into a write-output statement?

There are basically three ways of using parenthesis in PowerShell: grouping, method calls, and sub-expressions. Hopefully the explanations and examples below will help. Feel free to ask questions in the comments if I’ve missed something.

Grouping

The simplest use of parenthesis is similar to the mathematics use of grouping constructs. In fact, in it’s simplest form, it’s exactly the same as what you learned in math, and we use it to group calculations to determine the order of operations:

But in PowerShell, it can also group calls to cmdlets and functions, and can allow you to invoke methods and properties on the output of those cmdlets. This allows you to use operators or call methods on the output of cmdlets without first storing them in variables. You can add and subtract dates:

When doing a registry lookup, you can avoid getting all of the PS* properties, you can call a single property, for instance, to get the path to PowerShell.exe:

You can cast the output of a command to another type. So for instance, if you wanted to pick 10 random letters, you might use the fact that 65..90 are the ASCII values for A..Z, and then cast them to the char type:

Method calls.

All objects have methods. In order to invoke a method, you have to use parenthesis to “call: it. So for instance, strings have a bunch of different methods, which you can see with this command:

For instance to convert a string to all upper case, you call the ToUpper method:

Note that when you type the name of a method without the parenthesis, you don’t invoke it: "hi".ToUpper Instead, PowerShell does reflection on the method and gives you information about how to call it, what the overloads are, etc. You can see much of the same information in the output of Get-Member. When you have a method that takes parameters, you need to pass the parameters inside the parenthesis, separating them with commas if there’s more than one:

Sub-Expressions

PowerShell also has another way to use parenthesis: with a leading $ (dollar sign), they become a sub-expression, which is calculated before the containing expression … so for instance, you will notice that the Write-Host inside the sub expression will output first:

Of course, you can’t put two command pipelines (separated by the semicolon “;”) into a simple parenthesis, but you can in a sub-expression!

• Created a Virtual Launch Party for Lee Holmes’ 2nd Edition Windows PowerShell Cookbook
• Updated my SharpSsh Module (which I wrote about ages ago in Scriptable SSH From PowerShell) to accept PSCredential objects or passwords, use CmdletBinding and have parameter set overrides
• Updated my JSON Module to support Pipeline binding in ConvertFrom-Json and to call out the fact that it properly supports dynamic objects if you specify PSObject as the type.
• Updated (and finally released) my Presentation module

• Updated (and finally released) my PowerTest Module (it now has setup/teardown and supports filtering tests by name and category). This module needs it’s own blog post too, but you can get an idea what it’s about in the first hour of the Live Meeting recording of my Testing with PowerShell presentation.

Now that I mention all that stuff, there’s a few things from last week that bear mentioning too:

• I wrote a sweet little function to wrap the LoreSoft.MathExpressions assembly, which lets you do all sorts of math inline in the PowerShell console.
• I also updated my HttpRest module to work with the latest 2.1 release of MindTouch Dream

• And published my current PowerShell Prompt and PowerShell Profile

And if you haven’t seen them … the week before that I also

• Published a function for invoking Generic Signature Methods from PowerShell which was something I had previously considered impossible.
• Made some very nice updated to ConvertFrom-PropertyString which parses ini files and anything like that…
• Published a trick for getting PowerShell.exe to run in .Net 4 and to allow PowerShell to load binary modules from network paths

• Wrote a function to generate proxy wrappers for OData Services which was closely followed by a full PowerShell OData Module from Doug Finke

So, I’m giving myself a break.

In PowerShell you always have three named variable scopes: script, local and global. The default scope is always the same as the local scope, so when you set a variable without specifying the scope, it’s always set at local scope. One thing to note is that you can access these named scopes through the $variable notation, or through the variable drive, so all of the following are equivalent:

A side note: the PSProvider drive notation means that when you’re in strict mode, if you want to test for the existence of a variable without causing an error, the simplest way to do it is with Test-Path Variable:Var…

What’s so hard about that?

Well, the question is: what scope are you in “right now” when a line of code is executing from a function or a script …

Sometimes local scope is ALSO script scope, and sometimes, script scope is also global scope. Specifically: when you’re typing at the console, all three scopes are the same.

Let’s write a function to determine what named scope we’re in:

By setting a variable, and then testing the named scopes, we can verify what scope we were in when we set the variable. Of course, there’s no point testing the Local scope, because we already know that is where we are… then we return a hashtable of booleans indicating which scopes are active.

If you dot-source that Get-Scope function, you’ll find the scope that you’re in where you dot-source it:

• if you do it at the interactive prompt it should tell you all three scopes are set
• if you do it in a script file it should tell you Local and Script
• but if you do it in a function, it will always just tell you “local” — and will not tell you if the function is in a script or not … nor how deep you are.

• and if you do it in a module, the results will depend on whether Find-Scope is defined in the module or not (this is very weird)

So are we done?

Not even remotely. On top of the named scopes, PowerShell also has nested scopes. Each script, function, scriptblock, etc. adds to the nested scopes, and takes you further from the global scope. On top of that, PowerShell has Modules. In a module, scope is flattened. Specifically, in a module, the default scope becomes the Script scope, which in this case is not actually reserved for a single file, but for any scripts, functions, etc that are executed from within that module’s context.

To determine nesting level of the scope, we must do something like this:

As long as modules aren’t involved, that will tell you how many scopes there are between you and global scope (and thus, return zero when dot-source from the console commandline).

This falls apart a bit if you’re in a module (in a module, you can’t get to global scope by increasing the scope value — effectively, the highest you can go is script scope, but in reality you can still access global scope by naming it). To determine if you’re in a module, you can simply check for the existence of the $PSScriptRoot variable, or verify that $Invocation.MyCommand.Module is set to something.

Additionally, if you’re in a module, you need to define this function in that module for it to work at all.

There’s one more thing you could use to help you learn what scope you’re in, and that is the Get-PSCallStack cmdlet. This will tell you how many commands have been called to get you where you are. It’s usually the same as the Scope Depth, but not when it’s in a script file, etc.

Here’s my finished scope digging function:

• Remember: modules sometimes flatten scope.

• Remember: when calling this function you should dot-source it, and pass it $MyInvocation

As as side note and counter-example, take for instance this module:

All three of those functions will return ScopeDepth = 2 (the test-scope function, and the module itself), but the StackDepth will increase correctly. I don’t know why. It’s late, so I’m going to stop writing before I get more confusing.

Incidentally, if you’re a geek and you don’t know that, you should try running WireShark while you download and send emails…

Anyway. The point of this email is to point out that Comodo (one of the biggest SSL Certificate vendors, and one who’s trust certificates are pre-installed on Windows) is giving away free secure email certificates which you can use in Outlook, Thunderbird, or whatever your favorite email client is. They’re actually on the recommendation list from Microsoft, but inexplicably listed under “other” office versions (they work fine in Outlook 2007, just to be clear).

All you need to do now is run off and sign up and then tell all your friends and family to do the same thing.

Edit: Someone just pointed out that I forgot the bit of my prompt that sets my current path into the window title, and I realized I also forgot the bit that puts (Admin) in the title if you’re running “elevated” on Vista.

Edit: Ok, how many people noticed that I incorrectly used the Environement.CurrentDirectory when I set the WindowTitle (meaning it would only work right in FileSystem drives)? Fixed now.

I’m going to show you how to make the “alias” command work roughly the way it does in bash, but first, let me clear this up:

In Bash, the recommendation is that “for almost every purpose, shell functions are preferred over aliases” ... and that recommendation is even stronger for PowerShell. The PowerShell “alias” is a true alias — it’s just another name for a command, script, function, etc. and it doesn’t support passing parameters or making mini-scripts at all.

Usually, an alias serves to give you a name you can remember, but sometimes it’s just to shorten the name, . Another use for them is to let you specify the default cmdlet — if you have two cmdlets (or script functions) with the same name, you can use an alias to override which one is executed by default.

The PowerShell function can do everything a bash alias can do (and everything a function or script can do, but this isn’t a tip about that, it’s a tip about making an alias and unalias command that works the way you expect it to). So …

You can save that as alias.ps1 and create your aliases the way you used to in bash alias ls='ls -recurse' and still be able to invoke them and, you can pass them extra parameters somewhat like in csh when you invoke them. I’ve added some extra text in the function name and content and in the alias description, so it’s actually pretty easy to find all the aliases and functions this script creates and dump them to a file so you can reload them later if you want … but I haven’t actually written a function to do that yet myself.

One important note: You must not use recursive aliases in the bindings on v1 — that is, alias ls='ls -recurse' will loop until it hits PowerShell’s recursive limit (only 100) and exit if you try to use it on v1 — because the script won’t be able to resolve the alias “ls” to Get-ChildItem … you’re probably better off not relying on that feature anyway.

Fixing the “Current Directory” problem

The core of this tip is very simple: Windows tracks your application’s “current directory” ... and you can get and set this location using static methods of the System.IO.Directory class: SetCurrentDirectory and GetCurrentDirectory.

The reason this is showing up as a Power User Tip is that PowerShell doesn’t set this environment setting when you navigate — it uses it’s internal “PSProvider” architecture, and doesn’t differentiate between whether you’re in a FileSystem location or a registry location, or even a third-party provider. So, it never actually changes the current directory, and any console command or .net method you call which uses the current directory will most likely be in the wrong place — like, for instance:

The problem is that now you don’t know where “NeatFile.txt” is — the “current directory” depends on how you launched PowerShell — most frequently it’s your $Home directory (equivalent to Env:HOMEDRIVE + Env:HOMEPATH — usually something like C:\Documents and Settings\YourName), but it could be your SystemRoot (C:\Windows) or the current directory of the app that launched PowerShell (eg: C:\Windows\System32 when you run it via “runas”). You can figure it out by running: [IO.Directory]::GetCurrentDirectory().

But here’s something more interesting: you can “fix” the problem by using [IO.Directory]::SetCurrentDirectory. There are a couple of catches, however: You can’t just use $pwd or Get-Location because you might be in the registry or some other location that’s not a Directory. And you can’t just use Get-Location -PSProvider FileSystem because even though it returns the current FileSystem provider path, the FileSystem provider supports “fake” PSDrives (eg: you could create a Scripts: drive like new-psdrive scripts filesystem "$Home\Scripts") and these aren’t actually supported by the .Net FileSystem. Luckily, PowerShell includes a Convert-Path cmdlet which was created for this very purpose: converting a path from a Windows PowerShell path to a native path supported by the underlying provider.

Without further ado, here’s a one-liner you can add to your prompt function:

Edit: You can do the same thing using the System.Environment class, and it turns out that the ProviderPath is a property of the PathInfo object, perhaps you’ll find this syntax simpler:

My first tip to power users is to remember the priority which PowerShell assigns to things by default:

1. Alias
2. Function (and Filter)
3. Cmdlet
4. ExternalScript
5. Application

1. Files with associations

This means that using an Alias, you can override anything (and since you can’t have multiple aliases with the same name, that makes aliases the ultimate way to disambiguate commands).

Functions and filters (there’s really no such thing as a filter) come before cmdlets (yes, even built-in cmdlets) and scripts (that is, your .ps1 files which are in your path, and are called “ExternalScripts” by PowerShell) come before applications, which come before scripts written in other languages, like .vbs or .bat or .cmd (even though they’re all shown as “Application” type commands, PowerShell prioritizes apps over executable scripts which are associated with an engine).

Incidentally, I’m not actually sure what a “Script” is (it’s a CommandType for Get-Command, but there aren’t any on my PCs) if anyone can run get-command -type "Script" and get something output, please let me know what it was.

It’s important to understand that this precedence order is not what you get if you run Get-Command (Get-Command merely orders everything alphabetically by name). In fact, as far as I know, PowerShell doesn’t give you a way to get a list of commands in the order that they would execute, nor does it specify any way of determining that order in the documentation. If you would like to see the proper order, you could use the following “filter” function, and sort by Order bearing in mind that it really only works precisely when you type the full command without wildcards.

Oh, by the way, in case it’s not obvious … “luimcxp” is the second letter of each “CommandType” (which is unique in each one) in the order that I think they belong in … so IndexOf( $($_.CommandType)[1] ) gives us the correct ordering for the command in $_.