How to list all installed, runnable cmdlets in powershell?

Question:

I want to list all installed, runable cmdlets and functions in powershell but Get-Command is listing cmdlets which are somehow “there” but not loaded and not runnable.

As an example, Get-Command lists New-IseSnippet:

So it looks like we have a New-IseSnippet command – let’s inspect it:

Nope, can we run it?:

Nope.

How do we get only installed, runnable commands?

Answer:

As for this root query …

I want to list all installed, runable cmdlets and functions in
powershell

… In my personal library, here is part of a snippet I created/put-together, a long time ago and update as needed, for exactly this kind of use case. There is far more in my snippet, but this should get you what you are after as per your post. This being my my snippet library in ISE / VSCode, I bring it up anytime as need using CTRL+J and selecting it in the ISE and just typing Help in VSCode and selecting it.

As already noted, there are things (not necessarily modules / cmdlets always) that are ISE only (that’s anything in the ISE module or the like of course) depending on what you are after / doing, such as lots form stuff, but as long as you add the appropriate form classes / types to your code, they should run just fine in the consolehost as well.

Yet, it is not correct to think that anything that is marked as ISE would ever run anywhere else. There are lots of ISE addons as well. You can get to them via the ISE Add-Ons menu. Anything in that menu should never be expected in the consolehost. For example, that is a built in tool to open a text-based files in an ISE editor tab directly, psEdit.

Trying to use that in the console host will fail, since the console host does not have such an editor.

You can programmatically do things in the ISE as well, and of course this sort of thing would never work in the consolehost.

See details here:
The ISE Object Model Hierarchy

To make sure stuff is where it should be when you need it, adjust you PowerShell profiles. For example here is a sample of what mine has in it to deal with when I am in the ISE vs the consolehost.

Update for the OP

As for …

So, is there a way to query commands which are actually loaded and
runnable in the powershell.exe (or pwsh.exe) console?

Not in the sense I take you are thinking. You seem to have a concept of what cmdlets are loaded on startup. That’s not a thing. cmdlets are exposed by module loading, and paths. What you are expecting is for PowerShell to only display modules / cmdlets / functions based on what PowerShell version / environment you are in. That is not a thing either. PowerShell will have access to all of .Net on your system and anything in the defined paths. Whether you load and use them or not, is a different matter.

If you are on PSv3 and higher, anything is your system environment and PowerShell paths are always available, as anything you call in the path would be auto-loaded when you try and use it.

Again Get-Command will list all available, they are only loaded when you call one, and gone when the call or session is done / closed of course.

If you have modules, cmdlets / functions not in the expected (environment or PS paths) places, then you either have to add that path or use the use the UNC path to them to run them. So, anything in the paths, dot-sourced from any UNC, are always available. If you are in the ISE, you can see this in the Commands tab, or in the console by using Get-Command.

You can add paths temporarily on the fly or using your PowerShell profiles or permanently on the fly, via your PowerShell profile, or using the Windows Environment variable dialog.

The consolehost and the ISE will always list any module, cmdlet, function in the expected paths. They does not mean that are all usable. As noted the ISe specific modules, cmdlets, functions will only work in the ISE for obvious reasons. Yet, the ISE will run any module, cmdlet , function the console host will, except for PSReadline. Well it will load it, but it won’t do anything in the ISE console. The ISE console is really an output windows not a the same thing as the consolehost. Well, you can do consolehost like stuff in it, but it’s not the same thing.

So, modules are loaded, modules expose the cmdlets / functions in them. Not all modules are loaded by default, hence the reason for the two command above, this is why Import-Module and auto load on call, exists. Standalone personal module / cmdlets / functions / scripts are not something PS will know about until you tell it where they should be imported / loaded / used from.

If you are really curious about this sort of thing you can leverage the Trace-Command cmdlet …

Trace-Command

… with your code to see what is actually being called and you will see that it is called each time you run the code.

The more modules you install, the moire cmdlets / functions become available. If you really think about this for a moment, their are hundreds of modules out their, and thus thousands of exposed cmdlets / functions. Why would you want all that loaded in memory. Your system would just fail due to resource exhaustion. So, only load what you really need, PowerShell will only call what it needs when it needs it. Know what is ISE specific and ignore all of that if you intend to live in the console host, or live in the ISE / VSCode, and shell out to the consolehost only when needed. This is how I do things. I rarely, if ever need to go to the console host for anything. ISE is my default, VSCode is my secondary (for now). There are those who poo-poo the ISE, I am not one of those types.

Update for OP

As for…

My use case is not a user sitting at a PC but a NodeJS application
which runs the powershell.exe (PS5) or pwsh.exe (PS6/Core) host. I
totally get that modules may be “available” but not loaded and that’s
what I want to query: which cmdlets/functions are loaded (i.e.
available to be run now without loading a module). I find it
weird/buggy that Get-Command * will list Cmdlet X but Get-Command X
wil crap out. How do I query a command: are you loaded runnable? PS:
Google “powowshell” to see my project.

It would have helped just to put the link to your project vs making me search for it. 8-} and the fact that it only shows in in Google and not other engine like DuckDuckGo or Bing is a bit odd, but oh well.

So, you mean this collection —

http://cawoodm.blogspot.com
https://github.com/cawoodm/powowshell.

I’ll take a look. Yet, for what you are after, don’t use Get-Command by itself. Use Get-Module in concert with Get-Command to list the cmdlets / functions from those loaded modules, to get closer to what you are after. By doing it this way, only the loaded modules and the associated cmdlets / functions for that session are listed.

Update for OP

As for …

Your solution wil fail to list cmdlets/functions (e.g. ForEach-Object
or Stop-Job) which have no module association (64 on my system). Also,
how sure are you Get-Module returns only loaded modules?

PowerShell gets cmdlets and functions from PowerShell sources and Modules.

If you do a lookup on the cmdlets / functions you are pointing to, you will see where they come from here:

So, the base cmdlets / functions are not from an Import-Module effort. There are just there by design in the OS/.Net install.

So, my solution is not a fail and I never said it would get you 100% by using that. It was a way of showing you what modules load for use what cmdlets / functions and that has little to nothing to do with what Microsoft.PowerShell.Core, .Net holistically and/or what the OS version allows (Cmdlets/Functions/Modules are also OS and $PSVersion specific as we all know).

So, again, your use case for what you are trying to devise is not valid. Cmdlets and functions, regardless of source are not loaded and ready for use. They are installed or exposed and available for use when you need to call them via the aforementioned. They are not ever loaded (sitting in memory) until you call them, no more that anything in the GAC is.

So, looking at you project, I see what you are trying to do, but you are trying to think for the user. Just as you as a developer have to reference an assembly from the GAC (which has thousands of things that are there, but are not loaded until you reference them), and you have to know where it is and which one you want to use and why. So, goes the same mindset for what PowerShell can have access to. Note, I said access to, not whether you can use it or not in a PowerShell session.

So, if we step into this, we get…

So, again, you thought has to be, what is available, or made available when modules or DLLs are imported. Imported modules and their associated cmdlets / function may not work, depending on what type of session you in.
Meaning, ISE vs consolhost.

FYI, you have to widen you view of this…

In the ISE


In the consolehost – note the differences

Source:

How to list all installed, runnable cmdlets in powershell? by licensed under CC BY-SA | With most appropriate answer!

Leave a Reply