Learn about Windows PowerShell
Summary: The Scripting Wife learns how to create a Windows PowerShell ISE profile.
Note This is part two in a series of articles in which The Scripting Wife learns how to work with Windows PowerShell profiles. In yesterday’s article, she created a profile for the Windows PowerShell console. That article also covers the basics of loading and checking commands. You should read that article before reading this one.
Microsoft Scripting Guy Ed Wilson here. It was the kind of stillness that can be heard. The early morning fog hugged the ground like a cloud that grew tired of floating. In my mind, I could hear the mournful strains of a saxophone as it intoned rich emotions with every note. A far-away diesel truck used its air brakes to arrest the runaway descent on a pernicious downgrade. As I sat on the lanai, the silence of the early morning stillness was nearly overwhelming.
I returned inside for another cup of English Breakfast tea, and I heard a rustling of papers as I entered the kitchen. I peeked around the corner.
There sitting at her computer is The Scripting Wife—and the sun is not even up yet!
“Good morning, Scripting Wife,” I said cheerily.
“What’s so good about it,” she replied.
“Well, for one thing you are awake to greet the day,” I said.
“The day will happen with or without a greeting from me,” she replied.
The Scripting Wife looked at me with a studied eye. She paused as if forming her words carefully.
“Just what are you made up for this morning?”
“Down these mean streets a man must walk who is himself not mean,” I said.
“You are not Philip Marlow, and you certainly are no Raymond Chandler,” she replied matter-of-factly.
“That’s right, but Bouchercon is only three days away, baby,” I said.
“You are not going to prance around here in a trench coat and fedora for three days! Besides, I am not certain that a Windows kind of guy should even be seen wearing a fedora,” she intoned.
“Those words hurt baby. They hurt me bad, but I know you did not mean them. So what’s up?”
“Well, yesterday you told me how to add a profile to Windows PowerShell, but when I open the Windows PowerShell ISE, I still have to manually load the PowerShell Community Extensions module. So I guess the profile is not working,” she replied.
“I know what your problem is, baby; but I cannot just out with it. You will need to discover it for yourself,” I said in my best Bogart imitation.
“So, are you going to help me?”
“Yeah, I will help you. Open the Windows PowerShell ISE and show me what you have tried.”
The Scripting Wife opened the Windows PowerShell ISE from inside the Start/All Programs/Accessories/Windows PowerShell folder. When the Windows PowerShell ISE was loaded, she typed the following command in the bottom pane (the command window):
Get-Command –module PSCX
The command and associated output are shown in the following figure.
“Ok, so it looks as if you have not loaded the PSCX module. Another way to check this is to use the Get-Module cmdlet. The Get-Module cmdlet, with no parameters or switches, reports on the modules that are loaded. Try it.”
The Scripting Wife typed the following command in the bottom of the three panes that make up the Windows PowerShell ISE:
“Nothing happened,” she complained.
I looked over at her screen, and while no output from the command appeared, the command had run because it appeared in the output pane. Her screen output is shown in the following figure.
“Ok, so you are not loading the PSCX module. Do you have a profile?”
“Well, duh, we created one yesterday,” she said caustically.
“We created a profile from the Windows PowerShell console, but we did not create one for the Windows PowerShell ISE. They are separate profiles, and they can contain different commands. For example, you might want to use something that would apply to the Windows PowerShell ISE, but not to the Windows PowerShell console. In my profile for the Windows PowerShell ISE, I create custom menus. Those commands would fail inside the Windows PowerShell console,” I said.
“That makes sense, I guess,” she said. “So how do I create a Windows PowerShell ISE profile?”
“You do it exactly the same way you did in the Windows PowerShell console. You even use the same $profile automatic variable.”
The Scripting Wife thought for a few seconds, and then she typed the following command. The first thing she did was use the Test-Path cmdlet to see if she already had a Windows PowerShell ISE profile:
When she confirmed that the Windows PowerShell ISE profile did not exist, she used the New-Item cmdlet to create a new profile script. She used the $profile automatic variable to ensure the name of the file and the path would be correct. This command is shown here:
New-Item $profile -ItemType file –Force
The two commands and their associated output are shown in the following figure.
“You could open the newly created Windows PowerShell ISE profile in Notepad, just as you did yesterday, but because you already have the Windows PowerShell ISE open, why don’t you open it there,” I said.
“Ok, but how do I do that?”
“Well, you could use the File/Open dialogue box, but that box is rather inefficient. It wants you to manually navigate or search to find the file that is represented by the $profile variable. Unfortunately, it does not know what to do with a Windows PowerShell variable,” I lamented.
“That is not helpful, Script Monkey. I want to know what I can do, not what I cannot do,” she said with mock frustration (at least I think it was mock frustration).
“Ok, in the command pane, type ise space dollar profile.”
The Scripting Wife did not hesitate. Here is the command she typed:
“At the top of the Windows PowerShell ISE, add the command to import the PSCX module, and save the file,” I said.
The Scripting Wife immediately typed the following command at the top of the profile file that is loaded in the Windows PowerShell ISE:
She then saved the file, and closed and reopened the Windows PowerShell ISE. After she had opened the ISE again, she used Get-Module to ensure the PSCX module had loaded. She also opened her $profile script back up in the ISE to inspect it. Here are the two commands she typed:
“Cool,” she exclaimed, “way cooler, anyway, than that silly hat you are wearing.”
“Well, I am out of here. I am getting together with a couple of friends, and we are heading to the spa,” she said.
“I did not know that spa treatments were social activities.”
“Oh, they can be. Most certainly, they can be. See you later, gator.”
With that, she cleared the room. Outside, the fog had lifted. A beautiful day was in store.
I invite you to follow me on Twitter and Facebook. You can also follow The Scripting Wife on Twitter. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
it is perfectly OK to have two different profiles for ISE und Console mode!
The ISE may have to deal with different settings that make not sense to the
But we may have some (or even a lot of) common settings in both files that we
don't want to maintain in two different locations. One solution maybe to have
a network place where we load the common settings from as part the execution of each profile. We may even use one profile file and distinguish the hosts by $host.name.
But it gets more complicated, if we want to extend this procedure to "All Users" and maybe
we have to distinguish between running in normal mode and elevated mode (admin) too!
If you have additional hosts ... it adds to complexity.
So it's really a bit of a challange to get it right for your special environment if you want to maintain profiles with a minimum amount of effort ...
If you have some good advice, please let us know! :-)
I use the same profile for both. For ISE related stuff, like the above mentioned custom menus, I do something like
@Klaus You are right, it is perfectly fine to have TWO different profiles ... one for console, and one for ISE. It is actually the way that I have my own personal laptop configured. You are also correct that there are a lot of settings that overlap. There are several different profiles ... I have written extensively about profiles on the Hey Scripting Guy blog - use the Windows Powershell, and profiles tags in the tag cloud to see all the articles. Some of the earlier ones discuss the different profiles. For example, you could put all the common things in the current user in $PROFILE.CurrentUserAllHosts, and then only place the host specific (either console, ise or some other host) in the $PROFILE.CurrentUserCurrentHost profile. If you want to have something that will be of value to all users in all hosts, then you place it in $PROFILE.AllUsersAllHosts. Obviously, this last profile would only have a few things in it, and would require admin rights to create and to install ... but it could be done by a company at OS install time to provide a standard set of aliases and functions -- this is, by the way, one way to address the question you had yesterday about becoming used to a particular function or alias, and having problems when going to a different machine. A company wide, standard profile solves that problem.
@Pat that is a great way to solve the problem, and to simplify things too. One profile with specific sections for the Windows Powershell console, and the ISE.