Before we wrap up,
there is one more area I want to touch on because it can
affect how you run commands in PowerShell.
This will especially become important when you start writing
your own PowerShell scripts and functions.
Now, PowerShell by itself is nothing more than an engine, like a car engine.
It needs to be inserted into a vehicle in order to really use it.
In our case, PowerShell has to be hosted in an application.
Now you don't have to worry about this other than understand that
there is a difference between the host and PowerShell.
When you run a PowerShell command, it writes objects to the PowerShell pipeline.
This is what allows you to do a lot of work from a
Command Prompt with minimal effort.
For the most part,
this is how you should be working with PowerShell; objects in the pipeline.
However, you can also interact directly with the hosting application.
There are commands in PowerShell that let you write to and read from the host.
It is the writing part that trips up a lot of beginners.
You can only work with objects that are written to the PowerShell pipeline.
If you write to the host, all you can do is read and
write whatever is on the screen.
And this will be much easier to see in a demonstration.
I need to make sure you understand about the PowerShell host.
Understand why commands in the pipeline are really important.
Make sure you understand the ins and outs of using write‑host.
And since we're at it,
I might as well show you read‑host, although this is something
that you probably really won't get into until you start doing
your own PowerShell scripting.
All right,
so let me show you what I'm talking about between the host and PowerShell.
And when I say PowerShell,
what I'm really talking about is the PowerShell pipeline.
This is something that trips up a lot of PowerShell beginners.
So I'm going to look at a built‑in variable called $host.
So you can see that I'm running in the ConsoleHost, and
that also shows you the version.
And I'm going to do a couple things here.
They'll all look the same.
So I'm just going to type the string "apple," and PowerShell shows me apple.
I'm going to use a cmdlet called Write‑Output,
and I'll do the same thing with Write‑Host.
Now, as far as you can tell, it looks like they all did the same thing.
And if all you're doing is just reading what's on the screen, yeah,
maybe it really doesn't matter, but it will matter.
So I'm going to take that string "apple" and pipe it to Get‑Member,
which is a command that I'm going to cover in the next module.
So this shows me that "apple" is a string object and Get‑Member shows
me all of the methods and properties of that object.
This works because something was written to the pipeline
for Get‑Member to know what to do with.
Let's take write‑output, repeat the process. Again, I get
an object written to the pipeline that Get‑Member can
consume and do something with.
Now let's try with Write‑Host.
I see the string there apple, but I also now get an error message.
You must specify an object to the Get‑Member cmdlet,
and this is the big distinction.
Write‑Host does exactly what the name is implying.
It's writing to the hosting application.
It's not writing output to the pipeline.
It's not writing to PowerShell.
Now, this can be sometimes useful, by the way,
so don't don't get the idea that Write‑Host is totally bad.
If we look at help for Write‑Hosts,
you'll see that there are some options there where you can specify formatting
for colors of the whatever it is that you want to write.
So if I wanted to, I could write a message to the console saying,
just kind of silly here, "A is for Apple," but display it in a red
color. When I see that, I now know that that output is not part of
my script or not part of the command, it's written directly to the host.
Now here's where it kind of gets interesting now that I think about it.
We now have all this capability of doing ANSI formatting, so you could
actually write an ANSI‑colored string to the pipeline.
It would be displayed in color, but would also be written to the pipeline.
So my little idea of only using color with Write‑Host may or may not be useful,
but it is an option there.
The difference that you have to keep in mind is you can only deal
with objects that you have written to the pipeline using
Write‑Output, what you really don't need, just let PowerShell do its
thing, and then consume those objects.
Using Write‑Host is telling PowerShell, take whatever this is
and just display it to me so I can look at it.
I really can't do anything else with it.
All right, so here's something else.
I'm going to create a variable called "Jeff." Most of the
time, that's really all you need to do.
Just define the variable,
assign it a value, and you're ready to go, and you can use it.
I can just do $Name and it shows me the name of the variable.
You can, however,
use the hosting capabilities to prompt using Read‑Host for a
value. So I could say Read‑Host and give it a prompt, hey, "Enter
a service name." And let's put in bits.
So now $name is the name of a service,
and if I do Get‑Service, or using the alias gsv, and my
variable, I can see that is working.
This also works, this Read‑Host for credentials, or should I say secure strings.
So I can say, hey, enter a credential for the password for the username.
Now, put something in. Now that Get‑Credential, by the way,
all it's doing is allowing you to input a credential.
I have no idea if that password I put in was correct or not.
I won't know until I use that.
But you can see, though, that it masked the password and I now
have a credential object that I could use with other commands
that might take a credential object.
I'm not going to demo anything like that right now.
You probably really aren't going to use Read‑Host until you start scripting,
but I wanted you to see that it is available if you were doing something
interactively and you kind of wanted to be prompted or take advantage of that.
I've gone through a lot of demo in this module.
If you felt a little lost,
that's okay, and actually to be expected. Download the demo files and
try some of the commands in PowerShell yourself.
Now,
I know some people get worked up and feel a little bit
nervous about working at a Command Prompt.
Relax.
You're not going to break anything.
I'm trusting you're trying everything out here in a
non‑critical desktop. Using PowerShell to get your job
done is a simple three‑step process.
First, find the command you think you need to use.
Read the help and examples. And then lastly, run the command from the prompt.
Don't worry about scripting right now.
Focus on running commands from the PowerShell prompt.
So that's it for now.
I suggest you take a quick break,
stretch your legs, and then come on back to learn more about putting PowerShell to work.