Putting Scripts and Command-line Tools into Your Home Directory
One theoretically viable solution is to save scripts or command-line applications to your user home directory. You can see this location from a PowerShell prompt by entering
$home
In my case, the home directory is C:\Users\aka. So I would save the script Show-CommandResolution.ps1 to C:\Users\aka\Show-CommandResolution.ps1. Now, this does not precisely put the tool into my search path. However, if you prefix a command name with [.], PowerShell looks for that command in the current PowerShell location, which is initially your user home directory.
Saving scripts to your user home directory doesn't require any special permissions, and actually eliminates the need for command resolution for this command. However, it does have some drawbacks: It's awkward, sloppy, and if you use PowerShell's Set-Location cmdlet to modify your location, it won't work because the prefix [.] always searches relative to the current PowerShell location, and finally, tools are only available to the current user when they're kept in this location.
Using PowerShell Aliases
Another technique is to set up aliases for tools. I have the installutil command-line tool (used for merging multiple .NET assemblies into a single file) installed on my PC. It automatically installs to C:\Program Files (x86)\Microsoft\installutil\installutil.exe. At a PowerShell prompt or within a PowerShell profile script, I can simply set up an alias that points to the application:
Set-Alias -Name installutil -Value $env:windir\microsoft.net framework\v2.0.50727 installutil.exe
PowerShell will then automatically find program any time I type the name installutil. If you have command-line applications already installed to various locations automatically, this is a viable way to make them accessible. However, this method requires that you explicitly set up an alias for each tool. You will also need to set up the alias each time you use PowerShell unless you've added the alias to your PowerShell profile script and are using the same personal profile. For more details about configuring PowerShell profiles, see "What You Need to Know to Start Using PowerShell's Personal Profile Scripts," InstantDoc ID 97669 (http://windowsitpro.com/article/articleid/97669/what-you-need-to-know-to-start-using-powershells-personal-profile-scripts.html).
Adding a Custom Tools Directory
My preferred technique is to create a custom folder for tools, then add the folder to my search path. I keep all of my addon applications and scripts in that folder. I automatically get version control this way, as well. If I add a tool that uses the same name as an existing tool, I know as soon as I attempt to copy it; Windows warns me that the file already exists in the target directory. You can also synchronize the folder to removable media, which is an important feature as most of these tools are portable and are useful for daily work in various locations.
Although the net effect of adding a directory to the search path is the same no matter how you do it, you do have several options for how to add a specific directory. These options differ depending on where you want the directory to appear and how visible you want it to be.
With the first option, you put the added directory in the search path for all users and processes on the computer; this also makes it useful for accessing tools used from Cmd.exe. To do so, you simply add a semicolon and the folder path to the system's path variable. You can reach that variable by opening the System application from the Control Panel. On the Advanced tab, click the Environment Variables button to display user and system-wide variables, which Figure 1 shows.
In the bottom section for system-wide variables, select the Path variable, which Figure 2 shows, and click the Edit… button. You can then add the new directory.
Don't forget that you must separate the directory paths with semicolons. Also, if you're going to use a network location, use a drive letter mapped by all users, not a Universal Naming Convention (UNC) path.
The second technique is to add the directory with a statement in a PowerShell profile script. This makes the directory automatically accessible in all PowerShell sessions. PowerShell exposes classic shell variables through the env: drive, so to add the directory C:\apps\bin to your search path, you would simply do this:
$env:path += ";c:\apps\bin"
where += is a shorthand expression in PowerShell that means "add this to the variable I just named"; the above statement is equivalent to $env:path = $env:path + ";c:\apps\bin".
You can also use this technique from a PowerShell prompt as needed. I keep my portable scripts and command-line tools on a USB drive in a folder named bin. When I'm making a site visit and need the tools, I simply plug in the USB drive and check the drive letter assigned to it. Assuming Windows assigned the letter E to the USB drive, in my PowerShell session I simply enter
$env:path += ";E:\bin"
and PowerShell automatically searches E:\bin for unfound commands for the rest of the PowerShell session.
Using the PowerShell Directory
Another technique for making commands easy to find is to save any command files to a directory that's already in your search path, such as the PowerShell directory itself. The path to this directory is contained in the PowerShell variable $pshome, and is a location such as C:\Windows\System32\WindowsPowerShell\v1.0.
If you want to have machine-wide PowerShell profile scripts, you're already committed to inserting the scripts into this folder, even though best practices for application vendors are always to stay away from modifications to the Windows folder or anything within it. Using the PowerShell directory offers some advantages, beyond not needing to add a custom folder to the search path yourself:
- Tools copied here will be available to anyone on the system.
- Tools copied here will inherit permissions from the Windows directory.
- You don't need to add anything to the command search path. Since you might need to add one or two scripts to this location for machine-wide profiles, it's a known location that can be modified by administrators, and if you perform a complete uninstall of PowerShell followed by manually deleting this folder, you'll be able to eliminate bad modifications.
Unfortunately, there are also a great many disadvantages to using the PowerShell directory. In fact, the disadvantages outweigh the ease of use:
- Using a system or general application directory is a bad practice in general for developers. Although I find it reasonable for an administrator to do this selectively, and even though it's necessary for machine-wide profiles, the fact that this technique is off the beaten trail makes it a special customization that will be vulnerable to everything from losing file access on upgrades to losing files period if you need to perform a Windows reinstallation.
- This technique also makes it virtually impossible to segregate custom additions from core PowerShell files. You will encounter problems with trying to use it on 64-bit Windows; there are actually two different PowerShell home directories on those systems, one under System32, and one under SysWOW64.
- In Windows Vista, User Account Control (UAC) makes modifications to this location difficult.
All of this adds up to making a system folder unattractive as a location for storing your binaries.
Options for Accessing External Commands
Each of the following techniques might be suitable under different circumstances, although I don't use some of them. In general, the technique you use to access external commands will depend on your situation. Let's summarize the scenarios:
1. If you don't mind including a preceding [.] whenever invoking external scripts and never change your PowerShell location, you could simply stick tools into your home directory. Dropping tools into this location might work in a pinch and doesn't require any system modifications, but it's very sloppy and error-prone.
2. If you're an administrator for a system and want to have specific tools available to all users on the machine, you can put them into PowerShell's own directory. Note: This is not considered a best practice. You're likely to lose tools during an upgrade or lose access to them if you switch between 32-bit and 64-bit versions of PowerShell.
3. For general use, I prefer to use a custom tools directory that I've added to my system path. My binary tools on my main system at home are located in c:\apps\bin and scripts are in c:\apps\bin\scripts. I've added both to my search path. On a work network, you can use a shared network location that administrators automatically can map to the drive. This makes it easy to centralize tools administration.
4. For some tools, I also use aliases. For example, applications from Microsoft's Windows Software Development Kit (SDK) that I occasionally use need to be located in the same directory as specific files. To avoid having dozens of directories in my search path for these tools, I just create an alias for each one.
Whichever technique you use, it's worth your while to simplify access to tools you use every day. A few minutes spent configuring your system to find tools without extra effort will pay off on a daily basis.