Next,
let's turn our attention to running commands. As I
showed you in the slides, really,
all you need to do is once you know the command is just type
it out and hit Enter. And I can, in this case, get all the
processes on my computer. Now,
in order to demonstrate some of these commands and the concepts and techniques,
I'm going to use a command called Get‑Vegetable.
Now, this is a command that I wrote,
and it is part of a module called PS Teaching Tools,
which you can install from the PowerShell gallery in the download
materials. There's notes on how you can do that.
I find that using a non‑technical example, like vegetable, sometimes
helps a great deal in letting you focus on the techniques and concepts
without getting hung up on the underlying technology, so you're not
looking at services or user accounts or processes. We're just taking
something generic and focusing on the concept. Because once you apply
the concept,
it doesn't matter whether we're applying it to vegetables, this
fake object that I'm creating, or services.
The concepts apply across PowerShell.
Get some noun,
so we get a verb, get, and a singular version of the thing we
want to imagine, in this case, vegetables.
There we go.
So there's my default output. So I can do Get‑Vegetable, and I can
also look for help on how to run this command.
So you can see there are just a couple of parameters there, name, and
whether it's a root only. So I could Get‑Vegetable ‑name corn.
Remember, parameters, dash, the name of the
parameter, a space, and then the value, and they were just the corn vegetables.
Now that RootOnly parameter that you see up there,
notice there's no value after that.
That means it is a switch.
I only have to use that parameter in order, in a
sense, to turn that on in the command.
You don't have to worry about what it's doing under the hood; the
help will tell you. And in this case, it will say,
hey, only show me vegetables that are classified as root vegetables.
So if I run that here, and sure enough,
those as far as I know are root vegetables. All commands have the verbose
parameter because that's one of the common parameters.
However,
that parameter won't do anything unless the command has
been coded to do something with it.
So in my case, Get‑Verbose shows me a command that
found 17 items, it's processing, and then it's ending.
Not every command will do that; you won't know until you try.
So now that we understand kind of the concepts from that generic command,
let's go into PowerShell and try the same things.
So let's use Get‑Service and let's find all of the services that
start with win, and I'll use verbose just to show you that in
this case it doesn't do anything.
It doesn't hurt anything, but it also doesn't give me any added value.
Now, some parameters, as I mentioned, in PowerShell are positional.
If I do Get‑Service win*, PowerShell assumes that whatever I
put immediately after the cmdlet name, I must mean the name parameter.
And sure enough,
that's what happens. Now you can see this in the help, if I do
Help on Get‑Service and look at that name parameter, you can
see there that it is not required, which means it's not mandatory,
and it has a position of 0, meaning it's the first position.
If it was required, it would be named.
Let me show you that.
Let's look at another parameter, requiredServices.
There you can see that position.
See, it says named.
So if I wanted to use this parameter, I actually have to type it out.
And in this case, I kind of have to type it out anyway because it is a switch.
So I can do get service bits, so bits is the value for
the name parameter which is positional.
So I don't have to type ‑name,
but I do need to type ‑RequiredServices if I want to use that parameter.
So this is showing me all the required services that bits needs.
All right,
let's look at processes, just because there's some interesting
things here to show you in terms of parameters.
So I do help Get‑Process.
You can see there are a number of ways that I can get
a process, by name or process ID.
So I'm going to try get‑process. $pid is a built‑in
variable that shows you the current process ID of your
PowerShell session. And that failed.
But I see there there's Get‑Process,
and I should be able to give it the Id. How come that didn't work? Well,
if we come back here and look at help on get‑process
and look at that Id parameter, you can see its position.
It's named.
I have to specify and tell PowerShell, hey,
you need to use the Id parameter so that it knows what
that value $pid what it goes to.
So if I rerun the command and use ‑id and give it the value, now
that works, and that's what I am expecting.
So you have to be in the habit of reading the help so that you
totally can understand what PowerShell is doing,
why things work, or, more importantly, why things sometimes don't work.
Look here then now at some mandatory parameters. If I run
Get‑CimInstance and just stop it by itself,
I get prompted, because it says, hey,
there needs to be a ClassName for this command.
I need to know what types of CimInstance information do you want me to get.
So I'm just going to hit Enter just to get the error message, hey,
you have to give me something. Okay, and let's go back and look at help.
And I used wildcards here because I want to show you a couple things here.
The ClassName is required and it's positional,
which means,
right, I don't have to specify, I don't have to type the ‑ClassName
parameter. ComputerName, if we scroll down here, is not required,
but it is a named parameter. So if I want to use it,
I have to include the parameter name.
So let's kind of put these things together here. Let's do Get‑CimInstance
and get the win32_operating system for the localhost.
And I'm going to throw in verbose output just because to show you, this
particular cmdlet does have verbose output, and it will give you some
additional information which may be of value to you.
So there we go.
So the ClassName is positional, no parameter name, but ComputerName is
required. I have to specify that parameter if I want to do it.
If I just ran that command without ‑ComputerName and just put in localhost,
PowerShell would not know what parameter that belongs to.
And I probably would be getting an error. Help again. That is the answer to figuring out why things work or why things won't work.