I recently wrapped up a training class, and was surprised at how much confusion exists about what PowerShell profiles are, how they work, and so forth. So let's try to clear some of it up!
First, the official documentation can be found at http://technet.microsoft.com/en-us/library/dd315342.aspx. it's very much worth reading.
Second, understand that profiles are actually pretty simple from the shell's point of view. Microsoft's implementation of the shell host - that is, either the ISE or the console window - are simply hardcoded to look for four specific files, residing in four specific locations, each time the host application starts. I prefer to use the script \[My ]Documents\WindowsPowerShell\profile.ps1. That file doesn't exist by default, nor does the WindowsPowerShell folder under my Documents library. I have to create them both.
Once I've done so, I simply add commands that I want executed each time I open the shell. For example, my current profile looks like this:
import-module activedirectorycd \add-pssnapin my.snapinThat loads Microsoft's ActiveDirectory module, switches to the root of the C: drive, and loads a custom snap-in I've written. That gets the shell "up and running" the way I like it.
The benefit of using the profile.ps1 filename is that all of Microsoft's host applications - the console window and the ISE - will load it, so I get the same behavior. Other filenames, like "Microsoft.PowerShell_profile.ps1," will only run when a specific host opens - in that case, the console host.
I should note that non-Microsoft hosts - such as editors like PowerGUI, PrimalScript, and PowerShell Plus - are under no obligation to load these profile files automatically. They could choose to load them, choose to load nothing, or choose to load entirely different files. Most of them give you an options interface to control what they actually do, and you should consult their documentation for more information.
Want to see the exact filenames that apply to your system? Open PowerShell and run these commands:
# loaded by all Microsoft hosts$profile.currentuserallhosts# loaded only by the current host$profile# loaded for the current host no matter what user is running it$profile.alluserscurrenthost# loaded for all users for all Microsoft hosts$profile.allusersallhostsThose last two are special: They're intended to create a sort of "global" profile that will apply to all users - but, again, none of those files exist by default. You have to create them.
Try not to overthink profile scripts. They're not really "special" in any way - the applications that Microsoft wrote, powershell.exe and powershell_ise.exe, are just hardcoded to look for these files and, if they exist, run them.
Okay, actually, these are special in ONE way: When executed, they don't run in their own scope. That means whatever they do will "stick around" after the script finishes running. That's exactly what you want: You can drop whole functions into a profile script and be able to access those functions from the shell prompt.
Profiles are subject to your system's Execution Policy. For example, if your company uses redirected folders, so that your Documents folder is really on a file server, then PowerShell may "see" your profile script as being a remote script (e.g., coming from a UNC), and won't execute it if your Execution Policy is set to RemoteSigned and your profile script isn't signed. You can always sign it (read the about_signing help topic for more details), of course!
Do you have a profile script? What do you use it for?
0 comments
Hide comments
