The Easy Way to Use PowerShell to Work with Special Folders
Summary: Microsoft Scripting Guy Ed Wilson shows the easy way to use Windows PowerShell to work with the paths to special folders.
Hey, Scripting Guy! I notice that in lots of your sample scripts, you often use a folder named FSO, and it appears off of your C: drive. Why do you do this? Is creating an FSO folder really a best practice?
Microsoft Scripting Guy, Ed Wilson, is here. Last week was an awesome week. The Scripting Wife and I went to two different User Group meetings, and I had several great conference calls. Yep, things were pretty exciting down here in Charlotte, North Carolina in the United States.
One of the cool things about Windows PowerShell 2.0 is that it is nearly 100 percent backward compatible with Windows PowerShell 1.0. This means that things you learned in the first version continue to be useful. In addition, this means that blogs written for earlier versions and scripts written for earlier versions continue to be useful. The one major consideration is that the older materials might not take advantage of newer capabilities. In some cases, this is a non-issue, but for other things, this could be a problem.
EV, the reason I use a folder named FSO goes back a long time ago—a really long time ago. The C:\FSO folder is my scratch folder. It is a folder where I put temporary information, but it is more than simply the TEMP folder because it is a temporary folder I use only for scripts. Therefore, the c:\fso folder is more like my temporary script folder. I put both scripts and output in that folder. The reason it is off the root directory is so that it is easily accessible, and so the path to the folder does not consume a lot of space. This is also the reason for the name FSO, which you can tell is short. I have used a folder named FSO as my scripting temp folder for years. In fact the name FSO itself is a shortcut name that stands for FileSystemObject, which is an object that was often used in VBScript script (but it can be used in other languages, such as in Windows PowerShell) to read and to write to files.
Now, if I did not use a C:\FSO folder to hold files that I use for temporary script input and output, what else could I use? Well, for one thing, I could use a folder that I know will always be available. Luckily, in Windows, there are lots of these types of folders. In fact, they are called special folders. One of the problems with using these special folders is that they have really long paths.
A couple of years ago, during the wrap up for the 2010 Scripting Games, I wrote a blog titled How Can I Query the Contents of a Special Folder on a Windows 7 Computer in which I talked about using the Shell.Application object to list the enumerations and the values of the special folders. It is an excellent blog and you should read it after you read today’s blog.
One easy way to work with special folders in Windows PowerShell is to use the System.Environment.SpecialFolder enumeration. In Windows PowerShell you can easily obtain the path to any special folder by using the GetFolderPath static method from the System.Environment .NET Framework class. This is easier to do than it sounds. Here is the code to obtain the path to the mydocuments special folder.
You can use this value directly. For example, to get a listing of all the files in the mydocuments special folder, use the code that is shown here.
If you decide you want to use the mydocuments folder for your scratch directory, you should consider adding it to your Windows PowerShell profile—both your Windows PowerShell console profile and your Windows PowerShell ISE profile. You should create a short variable name to reference this location. Here is an example of a command that you could add to your profile.
$mytemp = [environment]::getfolderpath(“mydocuments”)
You could then use it directly as shown here.
If this is something that you do decide to do, you should, perhaps, create a subfolder inside the mydocuments special folder, rather than cluttering up the folder with a bunch of scripts and temporary files. The following image shows my current mydocuments special folder. In this image, note that there are lots of folders, and lots of files (well, you cannot see all the files, but trust me, they are there).
There is a Windows PowerShell folder inside the mydocuments special folder. It contains a number of folders and a few profiles. This folder also holds modules. This would actually be a great place to add a new folder to hold scratch script stuff. The command that follows uses the $mytemp variable created earlier.
New-Item -ItemType directory -Path $mytemp\windowspowershell\ScriptScratch
Now, of course, there is a sort of a problem. I want the new ScriptScratch folder to be my temporary folder, and to be called $mytemp. Also a better name for the current mydocuments location might actually be to call it $mydocuments. Here are the two commands that I use to accomplish this task.
Rename-Item -Path variable:mytemp -NewName mydocuments
$mytemp = “$mydocuments\windowsPowerShell\ScriptScratch”
Now, I check the values of these two variables.
PS C:\> $mytemp
PS C:\> $mydocuments
Cool, it works. I can now add these two commands to my two Windows PowerShell profiles.
$mydocuments = [environment]::getfolderpath(“mydocuments”)
$mytemp = “$mydocuments\windowsPowerShell\ScriptScratch”
EV, if you work on multiple computers, and if you are not certain that the ScriptScratch folder exists, you might want to add a test to check for the existence of the folder. For that matter, the WindowsPowerShell folder does not exist in the mydocuments special folder unless specifically created. That is what my Copy-Modules script does. (The Copy-Modules script is shown in my Windows PowerShell ISE profile).
Well, that is all there is to working with scratch directories—at least for now. Join me tomorrow for Windows PowerShell cool stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy