In the past week I have been looking at some Powershell best practices. One of these is to re-use Powershell parameter names so commands feel more intuitive.
Does anyone have a function for retrieving parameter names for all functions?
You can use the Get-Command cmdlet to retrieve all commands and select the parameter names:
get-command | % { if ($_.Parameters) {$_.Parameters.Keys }} | select -Unique | sort
jisaak's post will get you a list of commands as requested; the best practices I read recommended re-using the Powershell verbs which you can get by:
Get-Verb
Modules containing modules that don't use the standard verbs generate a nice error:
WARNING: The names of some imported commands from the module '***' include
unapproved verbs that might make them less discoverable.
To find the commands with unapproved verbs, run the Import-Module command again
with the Verbose parameter. For a list of approved verbs, type Get-Verb.
Related
I want to list which things are useable under \\root\ .However i don't know how to list or see which things i can use.Because,i am beginner in the powershell.
I am coding this thing:
wmic /namespace:\root\
(But i don't know which things i can use under root.And because of this, i cannot use anything :/)
How can i list which things could be useable under root ?
If someone can help, i will be really happy :D
I tried use "/?" but it didn't help.Also i researched on google BUT again i couldn't find something useful for myself or maybe i couldn't understand their solutions.
There is a WMI class of __namespace you can query:
Get-WmiObject -Namespace Root -Class __Namespace | Select Name
Name
----
subscription
DEFAULT
CIMV2
msdtc
Cli
SECURITY
SecurityCenter2
RSOP
PEH
StandardCimv2
WMI
MSPS
directory
Policy
Interop
Hardware
ServiceModel
SecurityCenter
Microsoft
Appv
I would recommend reading through about WMI. It covers some of the discoverability aspects, which are important because:
In a default installation of Windows 8, there are more than 1,100 WMI classes in Root/Cimv2
Newer versions of powershell use CIM over WMI with commands like Get-CimInstance. It's not worth worrying about for now, but it's good to look into while you're learning
WMIC is a separate exe from powershell, and doesn't return powershell objects. I would avoid it unless you're stuck to command prompt
Cpt.Whale's answer is helpful, but is uses the deprecated WMI cmdlets (from the Get-WmiObject docs page: "Starting in PowerShell 3.0, this cmdlet has been superseded by Get-CimInstance"); similarly, wmic.exe is deprecated (see note at the top of the page). Both are deprecated in favor of the CIM cmdlets, so the standard advice applies:
The CIM cmdlets (e.g., Get-CimInstance) superseded the WMI cmdlets (e.g., Get-WmiObject) in PowerShell v3 (released in September 2012). Therefore, the WMI cmdlets should be avoided, not least because PowerShell (Core) v7+, where all future effort will go, doesn't even have them anymore. Note that WMI still underlies the CIM cmdlets, however.
For more information, including the differences between these two sets of cmdlets, see this answer.
Thus, here are solutions based on the CIM cmdlets:
To get all namespaces nested inside another namespace, such as root:
Get-CimInstance -Class __Namespace -Namespace root | ForEach-Object Name
To get all classes inside a given namespace, such as root, by name:
Get-CimClass -Namespace root | ForEach-Object CimClassName
Note:
Append | Sort-Object to the commands above to get alphabetically sorted output.
The default namespace (also for the WMI cmdlets) is root/cimv2, which applies if you omit a -Namespace argument.
im running powershell v5 on my machine and i can't seem to run the command
GET-HELP -Category Provider.
Is there an alternative to this command which can be used in v5 or is it a command that's available to v3 Powershell?
While Provider is a valid category for help topics, none of the topics that ship with PowerShell use category Provider (anymore), as of Windows PowerShell 5.1 / PowerShell (Core) 7.2.x
See GitHub issue #8030
The next best thing is to use a wildcard-based search, using the Get-Help's (positionally implied) -Name parameter:
Get-Help *provider*
This will list all topics with the word provider in the name, which comprises both cmdlets with the word in the name and conceptual help topics (topics whose name starts with about_).
If you want to limit the output to matching conceptual help topics (as Get-Help -Category Provider may have done in Windows PowerShell versions prior to v5.1):
Get-Help *provider* -Category HelpFile
# Alternative:
Get-Help about_*provider*
[1] The valid categories are: Alias, All, Class, Cmdlet, Configuration, DefaultHelp, DscResource, ExternalScript, FAQ, Filter, Function, General, Glossary, HelpFile, Provider, ScriptCommand, which correspond to the values of a non-public enumeration type, System.Management.Automation.HelpCategory; you can obtain these values programmatically with (TabExpansion2 'Get-Help -Category ' -cursorColumn 19).CompletionMatches.CompletionText.
The topics that ship with Windows PowerShell v5.1 / as of PowerShell (Core) 7.2.x span the following categories: Alias, Cmdlet, ExternalScript, Filter, Function, HelpFile, as obtained with (Get-Help *).Category | % ToString | Sort-Object -Unique
Using Windows Powershell 5.1. when I look at help Get-Help -full, I read the following:
Parameters
-Category <System.String[]>
Displays help only for items in the specified category and their aliases. Conceptual articles are in the HelpFile category.
Required? false
Position? named
Default value None
Accept pipeline input? False
Accept wildcard characters? false
If I do a Get-Help * | Group-Object Category | Select-Object Name, I only see the following categories:
Alias
Function
ExternalScript
Cmdlet
HelpFile
I get the same categories in PowerShell v7.2
I am making a list of app packages installed on my system. In this specific case the ZuneMusic packages. I use the following command:
Get-AppxPackage -AllUsers -PackageTypeFilter Main, Bundle, Resource, Framework |
Where-Object {$_.Name -like "*ZuneMusic*"}
This will get me a list/result with 4 packages. I can see some have IsResourcePackage : True and one has IsBundle : True etc.
It seems this has to do with the -PackageTypeFilter cause if I only use Main is get only one result. I Looked up the parameter -PackageTypeFilter description:
Specifies one or more comma-separated types of packages that the cmdlet gets from the package repository. Valid values are:
Bundle
Framework
Main
Resource
None
Can someone elaborate/explain a bit more what this -PackageTypeFilter parameter does please?
If I want to delete packages of apps that I do not use or want. Do I use all options of this parameter and delete all the results or is one specific option enough?
why dont you just do get-appxpackage -name *zunemusic* -allusers | remove-appxpackage?
dont use -packagetypefilter
the pipeline will get all the returned apps named *zunemusic* and remove them - however, if it floats your boat, specify each package individually
if you remove each package individually, possible future name changes could affect the script and will require manual update if so - probably unlikely though
I'm aware this topic has been answered quite a few times already, however, no solutions seem to work for me. When I use the following command:
Import-Module SkypeOnlineConnector
AND any/every combination of the following suggested solutions appended to the end of that command:
-DisableNameChecking
-WarningAction SilentlyContinue
-WarningAction Ignore
3>$null
| Out-Null
I get the following error message every single time:
WARNING: The names of some imported commands from the module 'tmp_ivxfpxoe.td2' include unapproved verbs
that might make them less discoverable. To find the commands with unapproved verbs, run the
Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb.
Any help would be greatly appreciated.
I come from a C, C++, C#, python background so i'm applying this thought pattern to Powershell which i'm learning from scratch but I'm a little confused so far as at first glance it seems to be inconsistent and does not follow a fixed base class type structure for all objects so that things can be queried in a consistent manner.
The following works fine:
$host | get-member
$env:username
So $env is a valid object but this does not work:
$env | get-member
These also do not work:
$env.gettype()
dir $env
dir $env:
but this type query on $host does so I'm assuming $host is a .net variable but $env is not?
$host.gettype()
I found that env: also works with dir (aka get-childitem) but this colon is yet another type of notation i'm unfamiliar with and things are starting to get very confusing now. This does not seem to be a string format in this case which I have seen some google posts about so what is it? It behaves like a member selection or dictionary key specifier. If it is a member selector or dictionary key then i would expect get-member to work because it is a standard object.
This outputs the variables and values that I wanted but I don't understand why this syntax is used. This is not DOS syntax either so what's going on here?
dir env:
But dir $env seems to equate to dir $env:userprofile???? why?
Therefore $host appears to be a .net object but $env or env: is something else completely different and I've no idea what object type it is in the grand scheme of things and cannot seem to query it's type with by conventional means. Initial thoughts are that it is a list object of sorts because get-childitem works with it but other than that I'm completely lost.
I'm clearly missing something here so can someone steer me in the right direction please?
Get-Help 'about_Providers' -ShowWindow shows that env: is drive in Environment Provider, i.e. one of Windows PowerShell providers.
BUILT-IN PROVIDERS: Windows PowerShell includes a set of built-in
providers that you can use to access the different types of data
stores.
Provider Drive Data store
-------- ----- ----------
Alias Alias: Windows PowerShell aliases
Certificate Cert: x509 certificates for digital signatures
Environment Env: Windows environment variables
FileSystem * File system drives, directories, and files
Function Function: Windows PowerShell functions
Registry HKLM:, HKCU: Windows registry
Variable Variable: Windows PowerShell variables
WSMan WSMan: WS-Management configuration information
* The FileSystem drives vary on each system.
You can also create your own Windows PowerShell providers, and you can
install providers that others develop. To list the providers that are
available in your session, type: get-psprovider.
That's why Get-ChildItem env: works in contrary to dir $env:, dir $env etc.
First thing to note is that $env and $env:username are not related. $env is just a variable and normally it does not exists, because nobody assign anything to it. Using colon in variable name (like $env:username, with exception to some predefined prefixes: global:, script:, local:, private: and variable:) is a special syntax, which allows to access to PowerShell provider item content with variable syntax. It works with any PowerShell provider which implement content cmdlets: ${C:\Windows\System.ini} or $function:prompt. That syntax is equivalent of calling of Get-Content or Set-Content for given PowerShell path.
My 2 cents:
Try get-psdrive and you will get something like:
Name Used (GB) Free (GB) Provider Root
Env Environment
So it seems to be something like a driver in batch.