My “getting started” series ran out of steam a bit partly because I didn’t get much feedback on them — maybe you’re not interested, or maybe it wasn’t easy enough, or was just too confusing. In any case, I want to put up at least this one last post to suggest that you get the PowerShell Code Repository set up, and to show you the final version of my profile script and how it loads the various pieces it needs, and then I’ll send you on your way.
Once you’ve got your PowerShell all installed and have set up your first profile to auto-load … you’re going to want some scripts (well, maybe you’ll want to learn more about how to use PowerShell, but go with me on this)!
One of the best places to look for scripts is the PowerShell Code Repository, and although you can browse and search on the website, you can also do it using the PoshCode module (or the version 1 compatible script). These scripts include a Get-PoshCode cmdlet which you can use with search terms to get a list of scripts and cmdlets back, or with numeric IDs to download scripts (you’ll see what I mean later on, for now, go ahead and grab the appropriate version of that script).
I’m going to assume you put it into your AutoModules folder. If you grabbed the module, it should be saved to WindowsPowerShell\AutoModules\PoshCode\PoshCode.psm1 otherwise, to WindowsPowerShell\AutoModules\PoshCode.ps1 … but you may have run into a minor problem if you load the .ps1 version ). Both the module and the script are signed, but they are signed by my self-issued code signing certificate which your computer almost certainly doesn’t trust… You can use the signature to verify that the file hasn’t been modified since I signed it, but that’s about all (and even that’s a bit of a trick). To actually use the script (module), you’ll need to sign the script yourself (see the steps and how to get a certificate in part 2).
If you’re on CTP2, this would be a good time to get my Authenticode script module to help with signing, and to learn a little about those PoshCode cmdlets … (more…)
This continues a short series of posts about getting started with PowerShell … with a few tips about things you can do to keep your PowerShell profile safe and organized. Your “profile” is the script that is automatically loaded when you start up PowerShell. Really, I should say that your profile is the set of scripts which are loaded by default when you start up PowerShell. “By default” because you can always skip loading them by passing the -NoProfile switch to PowerShell.exe, and a set because PowerShell does, in fact, attempt to load at least four scripts when you run it:
PowerShell loads “machine” profile scripts (which are located in the PowerShell folder) and “user” profile scripts (located in your Documents\WindowsPowerShell folder). But there’s a little more to it than that: PowerShell is a scripting engine which can be hosted inside any app, PowerShell.exe is a DOS-style console which is the default host. There are several third-party hosts available such as PowerShell Plus and PowerGUI and several open source hosts such as BgShell and PoshConsole … in order to support this ecosystem of hosts, the default PowerShell behavior is to load a host-specific profile script (for both the machine settings and the local-user settings). Not all hosts will do that, but anyway … the default host loads Microsoft.PowerShell_profile.ps1 and Profile.ps1 from both the user and machine locations.
By default, none of those profiles actually exist. Once you’ve installed everything as in Part 1, you should have a Profile.ps1 file provided by PSCX. This profile defines a whole bunch of values that are used by various PSCX cmdlets and scripts, so you may want to change some of it, but you should be careful about just deleting things until you’re well acquainted with the PSCX cmdlets. Over time, I’ve added settings to my profile for other snapins as well, and there gets to be a lot of noise in there that’s specific to different snapins, so instead of just leaving all of that in my main profile, I rename the Profile.ps1 file provided by PSCX and then dot-source it from a new blank profile script.
In fact, and I found that I started collecting a lot of scripts in my WindowsPowerShell folder so I created a sub-folder for them, and I automatically load everything that’s in that folder, so I don’t have to manually dot-source things when I add a new snapin profile.
In order to make sure that automatically loading scripts doesn’t become a way for people to attack my computer, I made a decision awhile ago that I would only auto-load signed scripts. The how and why of this is a bit much to get into, and I wrote about Generating Windows Authenticode Code-Signing Certificates with OpenSSL a while back, so you can read that if you want more details, I want to review the simplest steps. (more…)
I’ve decided to spend part of this weekend organizing my sock drawer PowerShell profile, and since there doesn’t seem to be a lot of best practices or prescriptive advice on setting up your PowerShell profile, I thought I’d write about how I do it, to help any new users out there get started.
If you are a .Net developer or a Computer Science researcher, and haven’t started using PowerShell, let me just make this argument for learning it:
PowerShell cmdlets are simple to write. The additional code required to make a .Net class into a cmdlet is very minor (at a minimum, a single method with a line of code to
Write-Outputsomething). Since cmdlets must derive from either Cmdlet or PSCmdlet you can’t just write every class as a cmdlet, but even non-cmdlet classes can be instantiated viaNew-Objectand their methods and properties can be exercised.After writing portions of a recent research project as PowerShell cmdlets, I would say that the ability to write a simple class and then use/execute from the command line and in scripts — plus the built in automatic argument parsing (PowerShell assigns pipeline input and command line parameters to object properties for you) makes PowerShell cmdlets quite useful for research and development. Because the overhead is so minimal, it minimizes the distractions of creating a user interface and allows you to focus your actual research goals. Additionally, because the PowerShell-specific code can be restricted to attributes and a method or two, the actual classes are still usable for other purposes. That is, your class is invokable within PowerShell, but it’s also reusabe within any .Net application, whether Windows.Forms, WPF, or even web apps.
Of course, since I’m primarily using PowerShell for research and development, I’m using the current CTP 2 release of PowerShell v2, some of what I’m doing in my profile won’t work until PowerShell 2 is released (next year?). I’ll try to mark the CTP-only features appropriately and offer PowerShell 1-compatible workarounds.
The first step, of course, is to install the software. To take full advantage of PowerShell 2, you need to have the .Net Framework 3.5 although you could use the .Net Framework 2.0 instead if you’re just using PowerShell 1.0. PowerShell 1 is only available as a “patch” so you have to choose the correct download for your platform through the Microsoft Download Center. However, since it’s still in CTP release, there is an installer for PowerShell 2 CTP2.
I also use the PowerShell Community Extensions and recommend them, although there’s a lot in there you may not use, there’s also a lot of extremely useful things — some of which are practically requirements. This package needs updating to work well with PowerShell 2, because PowerShell 2 has implemented natively some of the most popular features in PSCX, but it’s just a few minor changes. If you’re just getting started (or want to follow along with this series of posts), you should let PSCX install it’s profile (if you already have a profile, then in order to follow along with these posts, you should MOVE your profile out of the way before you install PSCX, and go ahead and let it create a profile from scratch).