The term is not recognized as the name of a cmdlet

A long time ago I wrote a blog post about what I recognized as a very common error when starting to use PowerShell.  You might have seen the error before:

The term ‘foobar’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

After reading the comments, I wanted to add a few other words about this error.  Anther common way to stumble unto this error is by trying to run a cmdlet without having loaded the snapin or module containing that cmdlet.

If you are attempting to run a cmdlet from a product such as Sharepoint, Exchange, or Sql, and you are getting “The term is not recognized as the name of a cmdlet…” it is likely that the required snapin or module has not been loaded.

I might explain more about snapins and modules in a later blog post.  For now, suffice it to say that they are both packages of cmdlets.  Snapins were used in v1 of PowerShell.  Modules came in v2 and have various advantages over snapins.

If you want to view what snapins are available to you, you can use the Get-PSSnapin cmdlet.  “Get-PSSnapin –Registered” will show you all the snapins that have been registered on your computer.  “Get-PSSnapin” will show you all the snapins that have been loaded.

To view the available modules, you can use the Get-Module cmdlet.  “Get-Module –ListAvailable” will provide you a list of the modules that are available on your box for loading and “Get-Module” by itself will show you all the modules you have loaded.

I hope that helps.

Finding out where my script is running (Part 2/2)

In the last part, we talked about how to figure out the path to your script, or where in the filesystem your script is located.  We saw that when a script starts running, a variable $myInvocation gets created and that this variable has information on how the script was invoked as well as a link to the ScriptInfo.  The ScriptInfo has information on the path to the script.

PS>’$myInvocation’ > foo.ps1
PS>$a = .\foo.ps1
PS>$a.mycommand | fl *

Path        : C:\Temp\foo.ps1
Definition  : C:\Temp\foo.ps1
Visibility  : Public
Name        : foo.ps1
CommandType : ExternalScript

It’s very common to want to access resources relative to the location of your script, e.g. you expect foo.xml to be in the same directory as foo.ps1.  By using split-path we can figure out the directory where foo.ps1 is located.

PS>’split-path $myInvocation.mycommand.path’ > foo.ps1
PS>.\foo.ps1
C:\Temp

Then we can use join-path to create the path to new files we expect in the same directory.  Here is a script that creates a new path for ‘LibraryScript.ps1′ which should be in the same directory as the script we are running.

PS>type foo.ps1
$myDirectory = split-path $myInvocation.mycommand.path
$myLibraryScript = join-path $myDirectory ‘LibraryScript.ps1′

$myLibraryScript
PS>.\foo.ps1
C:\Temp\LibraryScript.ps1

Once we have the path in the variable, it’s really easy to invoke the script via dot sourcing or ‘&’ as needed.  Note that we need to do this in the script and not in a function contained in a script as the function will have it’s own $myInvocation variable which has the CommandInfo for the function, not the script.  I constantly find myself adding those lines I just showed you and setting up the paths to all the helper scripts and data files needed by my script.

Finding out where my script is running (Part 1)

One common problem that people have when they start writing PowerShell scripts is figuring out where the script they are writing is located.  You’ll usually see people with this problem when they start writing scripts  that require other files, maybe because they split up the functionality into multiple files, or maybe because they require data contained in another file.  They know where the other file should be relative to where their script is located.  What they don’t know, is where their script is located. 

Whether you are writing functions or scripts, PowerShell exposes information about how your script/function was invoked in the $myInvocation variable.  I find it’s easier to learn what’s in there by examining it.  First, let’s create a two scripts, one which calls the other and the other which returns $myInvocation.

PS>’.\bar.ps1′ > foo.ps1
PS>’$myInvocation’ > bar.ps1

Now we can look at $myInvocation.

PS>$a = .\foo.ps1
PS>$a | format-list *

MyCommand             : bar.ps1
CommandLineParameters : {}
ScriptLineNumber      : 1
OffsetInLine          : 10
ScriptName            : C:\Temp\foo.ps1
Line                  : .\bar.ps1

PositionMessage       :
                        At C:\Temp\foo.ps1:1 char:10
                        + .\bar.ps1 <<<<

InvocationName        : .\bar.ps1
PipelineLength        : 1
PipelinePosition      : 1
ExpectingInput        : False
CommandOrigin         : Internal

There are a few things to notice.  First, you can see that we have information on where we are being called from in ScriptName.  We also have the line, where we were called from in Line, and the name used to invoke in InvocationName.  In this case, Line and InvocationName are the same because there was nothing else on the line, but had bar.ps1 been in a pipeline, I would have seen the whole line in Line and just the name I used to invoke the script in InvocationName.  So far, there’s nothing here that tells us where the script is located.  For that, we have to go to MyCommand.

PS>$a.mycommand.gettype()

IsPublic IsSerial Name                                     BaseType
——– ——– —-                                     ——–
True     False    ExternalScriptInfo                       System.Management.Automation.CommandInfo

PS>$a.mycommand | format-list *

Path        : C:\Temp\bar.ps1
Definition  : C:\Temp\bar.ps1
Visibility  : Public
Name        : bar.ps1
CommandType : ExternalScript

The first thing to notice is that MyCommand is another object of type ExternalScriptInfo.  If what had been called was a function, this would be of a different type, specifically a FunctionInfo.  This is, in fact, the same information that get-command would return if you passed it the path to your script.  It contains all the information necessary for Command Discovery to locate your script/function.  If you wanted to, you could invoke your script or function using this object like this:

PS>& $a.MyCommand

Another thing to note is that it has a Path property.  This property happens to have the full path to the script, which of course, is exactly what we need to get the directory where the script is located. 

In part 2, I’ll give you a common pattern used in scripts to get the directory where your script is located and paths to all your other files located in the same directory.

The term is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.

The title of this post is one of the most common errors you’ll see when using PowerShell.  It’s pretty literal.  It means PowerShell couldn’t find any command with the name you specified.

I’ve found that it’s very common to hit this error for two specific occasions.

1.  You mistyped the command you meant to run.

2.  You tried to run a command in the current directory but forgot to prepend it with .\

This second reason is a lot more common for beginners, especially if they are used to cmd.exe.   cmd.exe will search the current directory for commands, but PowerShell won’t unless it happens to be in the PATH environment variable.  This helps to prevent trojan attacks.  If you want to run a command in a directory not in your PATH you have to specify the directory.  For the current directory, a quick solution is to prepend your command with .\  For example, rather than running script.ps1,  run .\script.ps1

(A few more words about this subject here.)