Weekend Scripter: PowerShell ISE Not Only for Scripts
Summary: Ed Wilson, Microsoft Scripting Guy, talks about why you may want to use the Windows PowerShell ISE instead of the console.
Microsoft Scripting Guy, Ed Wilson, is here. I was speaking at a Windows PowerShell user group recently. After the presentation, someone came up to me and said that the Windows PowerShell ISE was rather confusing. Because he did not write scripts, he had not taken the time to learn how to use the ISE. Instead, if any Windows PowerShell needed “to be done,” he simply opened the Windows PowerShell console, typed away—and that was that.
Cool. I use the Windows PowerShell console all the time. In fact, on my computer, it remains open much longer on a day-by-day basis than Excel, Outlook, or even Word. But I also keep open the Windows PowerShell ISE. Why?
I find myself writing fewer Windows PowerShell scripts. Not because I don’t like to write scripts, but because I don’t have to script as much. With all of the way cool new modules, commands, cmdlets, and functions in Windows PowerShell 5.0 on Windows 10, lots of stuff that used to require scripts no longer do. So, I don’t script as much.
Why do I still use the Windows PowerShell ISE all the time?
This is an idea that I got from my friend, Lee Holmes. He said, “You can think of the Windows PowerShell ISE as a better Windows PowerShell console.”
Windows PowerShell is an application—to be more precise, it is a .NET application, and it can be hosted anywhere. You don’t hear much about it anymore because there is so much cool stuff in Windows PowerShell. But way back in the Windows PowerShell 1.0 days, one of the big features was that you could write your own application to host Windows PowerShell—that is, you could make your own shell if you wanted.
One of the coolest things I ever saw was a 3-D cube that had a Windows PowerShell console embedded on each of the six facets of the cube. You could type a Windows PowerShell command onto one side, rotate the cube and type another command, rotate the cube, and so on. With six instances of Windows PowerShell running at once, each doing different things on a different side of the cube—it was cool!
We chose to ship Windows PowerShell 1.0 (that is, the Windows PowerShell console) in the old-fashioned CMD prompt, basically, because it was familiar to people. But when we did that, it came with a whole host of limitations. There was only so much stuff we could do to the CMD prompt.
So we decided to write the Windows PowerShell ISE so that we could have a host that we could completely control. With the Windows PowerShell ISE in Windows PowerShell 5.0 having the transcript tool, there is no real reason that I need the Windows PowerShell console most of the time.
I have heard that resource usage or performance can be an issue, but I do not notice that too much. In fact, on my computer, the Windows PowerShell ISE opens and takes 96 MB of memory. The Windows PowerShell console opens and takes 46 MB of memory. If 50 MB of memory is a major issue on my computer, it is time for an upgrade.
A few things I miss
There are a few things I miss on in the Windows PowerShell ISE. One is the More command. The Windows PowerShell output pane in the Windows PowerShell ISE does not know what to do with More, so it ignores it. This means that a command that returns a lot of output scrolls and scrolls and scrolls.
Another thing that is a minor annoyance is that sometimes the insertion point gets lost in the output. I have to make certain that I am actually at the Windows PowerShell prompt when I begin typing or things get pear shaped.
It really annoys me that I highlight some script, press ENTER, and it does not go to the clipboard (like it does in the Windows PowerShell console). That is just a habit from many years of using the CMD prompt.
Additionally, the F-key command history appears to be missing in the ISE.
A couple things that are great
I love the shared variable environment between the script pane and the output pane. I can type multiline commands in the script pane and I don’t have to save it to run the commands. It is like a multiline command prompt.
I run the commands, and can access the variables directly in the output pane. For example, I can inspect the values without debugging. It is just a feature of the environment. In fact, I call this “impromptu debugging” because I am not invoking the debugger—but I can change variable values, and rerun my commands as many times as I want.
I can do all of this in the Windows PowerShell ISE, and never write a script. It is a great environment for doing Windows PowerShell. SQL Server MVP, Aaron Nelson, calls this “graphical PowerShell”—and I think that is a pretty good name for it.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments