Search results for 'app:weblogs' matching tags 'scripting techniques' and 'profile'

Use PowerShell Commands from One Session in Another Session

Anonymous — Fri, 25 Nov 2011 06:00:00 GMT

Summary: Learn how to automatically save commands from one session, and then use them in a new Windows PowerShell session.

Microsoft Scripting Guy, Ed Wilson, is here. One of the fun things about getting to travel around and talk to people who are using Windows PowerShell on a daily basis to automate their systems is the quality of the questions I receive. One question that has come up several times in the last month that the Scripting Wife and I have been traveling is, “How can I save my history when I exit Windows PowerShell, and then have that history available to me when I open up Windows PowerShell again?”

I gave this some thought…

I decided that it would be trivial to import automatically saved history when Windows PowerShell starts, and that the issue would be saving the Windows PowerShell history when Windows PowerShell exits. One student who was in my class in Irvine, California suggested that I automatically save each command into a history file as I type the commands. In this way, when I exit the Windows PowerShell console, I will already have an up-to-date history file. While this technique is not impossible, it could have an unintended performance hit, and I decided against it.

Another idea I had was to use the Windows PowerShell transcript. It is easy to start the transcript each time Windows PowerShell starts by adding the Start-Transcript command to the Windows PowerShell profile. I could then parse the Windows PowerShell transcript and pull out all of the commands. After I had all of the commands, it would be possible to add them to the history. But that would require creating a HistoryInfo object.

In the end, I decided to create two functions and add them to my profile. The first function imports a saved history.xml file into the current Windows PowerShell session. The second function exports the current history to a history.xml file, and then it exits Windows PowerShell.

The trick is to call the function that exports the history.xml file prior to exiting Windows PowerShell instead of clicking the “X” on the Windows PowerShell console, or typing exit to exit Windows PowerShell. As always, when I create a function, I also like to create an alias for that function. The two commands from my profile that create the aliases are shown here.

New-Alias -Name eps -Value Exit-PsWithHistory -description "mred alias"

New-Alias -Name ips -Value Import-PSHistory -Description "mred alias"

Instead of automatically importing the saved history, I manually type the alias for my import saved history function. The reason for this is that I do not always want to import my saved history; but, this is simply the way I work. I could easily modify my profile so that I do import my history automatically, and then I could simply clear the history if I did not want to use it. It will require a bit of testing before I make up my mind as to which action is most efficient.

Here is my function to export command history to a history.xml file and exit Windows PowerShell.

Function Exit-PsWithHistory

{

If(!(Test-Path $PSHistory))

{New-Item -path $PSHistory -itemtype directory}

Get-History -count $MaximumHistoryCount | Export-Clixml -Path (Join-Path $PSHistory -child history.xml)

Exit

} #end function Exit-PsWithHistory

The Exit-PsWithHistory function relies on the $PSHistory variable. This is a variable that I define in my Windows PowerShell profile, and it points to the folder I use to store my history.xml file. Here is the command that creates the $PSHistory variable.

$PSHistory = Join-path -path (split-path $PROFILE) -ChildPath history

So, I use the Test-Path cmdlet to see if there is a folder named History in my Windows PowerShell profile folder. If it does not exist, I create it by using the New-Item cmdlet.

If(!(Test-Path $PSHistory))

{New-Item -path $PSHistory -itemtype directory}

I then use the Get-History cmdlet to get all of the items in my command history. By default, the Get-History cmdlet returns only 32 items from the history. If I want to get all of the commands in my command history, I have to specify a value for the Count parameter. The most logical thing to do is to use the $MaximumHistoryCount variable to specify this number. In this way, if I increase the maximum history count from the default value of 64 to another number, my function will always export all of the commands. I use the Export-CliXML cmdlet to export my command history into an .xml file, and I use Join-Path to create the path to my file. This command is shown here.

Get-History -count $MaximumHistoryCount | Export-Clixml -Path (Join-Path $PSHistory -child history.xml)

The last thing I do is call the exit command to exit Windows PowerShell.

The function to import my saved history.xml file appears here.

Function Import-PsHistory

{

If(Test-Path $PSHistory)

{

Import-Clixml -Path (Join-Path -path $PSHistory -child history.xml) |

Add-history

}

} #end function import-psHistory

Once again, I use the Test-Path cmdlet to ensure that the history folder exists. If it does, I assume that a history.xml file exists. This is not a major problem, because the only reason the History folder would exist, would be if I had created it. If I did create it, it should have been when I was exporting a history.xml file.

If(Test-Path $PSHistory)

The next thing I do is import the xml file, and pipeline it to the Add-History cmdlet. Here is that portion of the function.

Import-Clixml -Path (Join-Path -path $PSHistory -child history.xml) |

Add-history

I bump up my maximum history by assigning a new value to the variable. Rather than typing a big, long, complicated number, I simply use the kb administrative constant to allow me to create 2048 history entries. This command is shown here.

$MaximumHistoryCount = 2kb

You might wonder, "How large can I create the $maximumHistoryCount variable?" To determine the maximum allowed value, I use the Get-Variable cmdlet. This command is shown here.

Get-Variable MaximumAliasCount | select -ExpandProperty attributes

MinRange MaxRange TypeId

-------- -------- ------

1024 32768 System.Management.Automation.Validat...

One thing to keep in mind, is when you use the Get-Variable cmdlet, do not include the dollar sign prefix. If I do include the dollar sign prefix of the variable, I obtain a rather cryptic error that states Windows PowerShell cannot find a variable with the name of 2048. Because I recognize that number as the value I had increased the $maximumhistorycount variable to, it makes sense. I then drop the dollar sign, and return the psvariable object. I then send the variable to the Format-List cmdlet, and I choose all of the properties. The result reveals that there is an object hiding in the attributes variable. I then pipe the psvariable object to the Select-Object cmdlet, and I use the ExpandProperty parameter to expand the object that is stored in the attributes property. These commands are shown here.

get-variable maximumhistorycount

get-variable maximumhistorycount | fl *

get-variable maximumhistorycount | select -ExpandProperty attributes

The commands and their associated output are shown here.

In the following image, I show my profile with the two new functions, the two aliases, and the two variable assignments.

To exit Windows PowerShell, I use the eps alias (my alias for the Export-PsWithHistory function. When I start Windows PowerShell, my profile runs, and it loads the functions, aliases, and variables into memory. I then type the Import-PsHistory command (I can also use the ips alias). After I do that, I populate my history with all of my previous commands. I use the h (alias for Get-History) command to see what commands I now have available to me in my command history. This sequence of commands is shown in the image that follows.

There is one downside to this technique: Imported commands (via Add-History) do not populate the up and down arrows. But, dude (or dudette), with 2048 potential commands in the command history, that would be a ridiculous amount of Up and Down arrowing; that is why there are single letter aliases for Get-History and for Invoke-History.

Join me tomorrow for the Weekend Scripter when I will explore more coolness related to Windows PowerShell.

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

The Scripting Wife Uses a Profile to Configure PowerShell

Anonymous — Mon, 12 Sep 2011 05:00:00 GMT

Summary: The Scripting Wife learns how to use a profile to configure the Windows PowerShell console.

Microsoft Scripting Guy Ed Wilson here. One of the coolest events of the year occurs in just a few days. Yes, that’s right, it’s Bouchercon in St. Louis. Bouchercon is a mystery writer’s conference, and the attendee list is a who’s-who among the cloak-and-dagger writer crowd. Conferees to Bouchercon also have the privilege of selecting the Anthony awards for the best mysteries.

It was a dark and stormy night in Charlotte, a town that knows how to keep its secrets, when a sudden disturbance in the other room cut through my concentration on my latest Windows PowerShell script like a dagger slicing through heavy drapery. As I moved stealthily through the foyer, across the living room, and into the kitchen, my eyes rapidly picked up the source of the cacophony of frustration-laden words that tumbled flat on the tile floor like yesterdays’ newspaper. I peeked around the corner.

“So, what’s ya beef, sweetheart?”

The Scripting Wife turned her gaze at me from her computer monitor and at that moment, I felt it. I felt it deep in the core of my being like a seven-inch stiletto plunged deep into my inner core, a spark of electricity that said she was the one. I looked down, and she was poking me in my stomach.

“I am not beefing. I have never beefed in my entire life. What is wrong with you anyway? What’s with the trench coat and the fedora?”

“A man on the job has to be prepared for all conditions, all emergencies, all kinds of stormy weather.”

“But we are inside. Besides, your Bogart voice is barely believable.”

“Don’t let the patter fool you, kid. Maybe I am not as tough as I am cracked up to be. Maybe that kind of a reputation is good for business. Inside, I might be a teddy bear, but don’t count on it. Besides, you knew it was Bogey.”

“Only because you always do Bogey. If you can get serious for a minute, I have a problem. Why do I always have to keep loading the PowerShell Community Extension Project every day?”

“Because you use it every day? That’s just a guess, but then my guesses are usually pretty good.”

“Of course, I use it every day, and that is why I need to load it.”

“Whadda I tell ya?”

“No. I mean, you never seem to load it, but I know you use the cmdlets. How is that possible?”

“Oh, I see what you mean. What you need to do is to create a profile. In your profile, you can load modules you find useful, and that you want to have immediately available,” I explained.

“Okay. So how do I get a profile,” she asked.

“Well the first thing to do, is to ensure that you do not already have a profile. Open your Windows PowerShell console, and use the Test-Path cmdlet to see if you have a profile. Use the $profile automatic variable to refer to your profile,” I instructed.

The Scripting Wife thought for a second, and typed the following command into the dark blue Windows PowerShell console:

Test-Path $PROFILE

As the Scripting Wife was typing, she took advantage of the Windows PowerShell tab expansion feature. Therefore, she did not have to type the complete command. What she actually typed was:

Test-p<tab><space>$p<tab><tab><enter>

In this case, <tab> represents the Tab key on the keyboard; <space> represents the spacebar; <enter> represents the Enter key on the keyboard.

On the Scripting Wife’s computer, Test-Path $profile returns False, which means that she does not have a profile. If your command returns True, you can open it in Notepad by using the following command:

Notepad $profile

To back up your profile, you can use this command (replace destination folder with a folder on your local computer):

Copy-item $profile destination folder

“Okay, I am assuming that I do not have a profile, because the Test-Path command came back and said False. So back to my original question: how do I get a profile?” she asked.

“It is simple. You use the New-Item cmdlet to tell it that you want to create an itemtype of file, and give it the $profile variable. Just to be on the safe side, go ahead and use the force switch.”

“You mean you are going to forgo your corny Star Wars ‘Use the force, Luke’ imitation?” she asked with a slightly disappointed voice.

“Yeah, you never seem to laugh at that one.”

“I never seem to laugh at any of them, but it never stopped you before,” she said.

The Scripting Wife said “New-Item $profile dash itemtype file dash force” to herself as she typed the following command:

New-Item $PROFILE -ItemType file –Force

The keys she actually typed are shown here:

New-i<tab><space>$pr<tab> <space>-i<tab><space>file<space>-f<tab><enter>

The reason the Scripting Wife used $pr<tab> was so that she did not have to tab past the $pid variable, which she had to do when she first used the Test-Path cmdlet. The commands and associated output are shown in the following figure.

“Obviously, it did something, but how is that going to automatically load the PowerShell Community Extensions for me?” she asked.

“Patience, grasshopper,” I said in my best Kung Fu voice.

“I think I prefer your Bogey to your Kung Fu voice. After all, I would rather be a babe than a grasshopper.”

“That reminds me of a Simon and Garfunkel song.”

“Oh, no!” she cried in mock horror. “Just get on with it.”

“Okay, now you have two choices: you can open your profile in Notepad, or you can open it in the Windows PowerShell ISE,” I explained.

“Let’s use Notepad. It is faster,” she said.

“All right. Type Notepad $profile,” I said.

The Scripting Wife did not hesitate as she typed the following command:

Notepad $profile

What she actually typed is shown here:

Notepad<space>$pr<tab><enter>

After she pressed Enter, a blank Notepad appeared, as shown in the following figure.

“Nothing happened,” she complained.

“Are you kidding? You opened Notepad, and not only that, look at the title bar. See how it points to the same location you saw earlier when you used the New-Item cmdlet to create your blank profile?”I asked.

“Okay,” she replied with a somewhat hesitant voice.

“Now, we will add the command to load the PSCX. After the command is added to your profile, it will happen each time you start the Windows PowerShell console. You ready?” I asked.

“You bet. Let’s do it.”

“Okay, in your open Notepad, add the Import-Module pscx command on the first line, and then save and close Notepad.”

She quickly typed the following command:

Import-Module pscx

“I wish that tab expansion worked inside Notepad,” she complained.

“What I do is type the command in the Windows PowerShell console first. Then when I know the command works, I highlight it and copy it, so I can paste it in Notepad. Now, close Windows PowerShell, and open it back up.”

“Ok. So how do I know that it worked?”

“Use the Get-Command cmdlet, and look for commands from the PSCX module,” I said.

The Scripting Wife used the GCM alias instead of typing Get-Command. Here is the command she typed:

gcm -Module pscx

The actual keystrokes she used are shown here:

gcm<space>-m<tab><enter>

The output from that command is shown in the following figure.

“Wow, that is cool. Thanks,” she said.

“You’re welcome, sweetheart,” I replied in my Bogey voice.

She sprung from her chair and left the keyboard as if it were a thing on fire. Her perfume reminded the now-empty room that a vibrant being had once occupied the premises. The room seemed smaller now that she was gone.

The Scripting Wife will return tomorrow when she struggles to configure the Windows PowerShell ISE. 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 scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy