{"id":51523,"date":"2010-01-20T00:01:00","date_gmt":"2010-01-20T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2010\/01\/20\/hey-scripting-guy-how-do-i-work-with-windows-powershell-module-paths\/"},"modified":"2010-01-20T00:01:00","modified_gmt":"2010-01-20T00:01:00","slug":"hey-scripting-guy-how-do-i-work-with-windows-powershell-module-paths","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/hey-scripting-guy-how-do-i-work-with-windows-powershell-module-paths\/","title":{"rendered":"Hey, Scripting Guy! How Do I Work with Windows PowerShell Module Paths?"},"content":{"rendered":"

\"Bookmark<\/a><\/p>\n

 \n\"Hey,<\/font><\/p>\n

Hey, Scripting Guy! I have been reading your articles about Windows PowerShell modules this week, but I am still a bit confused about where they go, how to get them there, and the best practice for dealing with them. Do you have any insight about how to actually work with Windows PowerShell module paths?<\/p>\n

— KG<\/p>\n

\n

 <\/p>\n

\"Hey,Hello KG, <\/p>\n

Microsoft Scripting Guy Ed Wilson here. I am drinking espresso this afternoon because I am answering the scripter@microsoft.com<\/font><\/a> e-mail. I have a small stovetop espresso machine I picked up in Naples, Italy, many years ago that I use to brew the espresso. I was up late last night reading David Copperfield<\/font><\/a> (Scripting Guys do not read only technical books), and I need an extra kick-start. I do not use any sugar in my coffee or espresso; instead, I place a cinnamon stick in the cup, a trick I picked up in Lisbon. As I sit staring blankly at my computer monitor, my mind wanders back to a similar time when I sat drinking espresso. Instead of being bundled up and freezing, however, I was wearing short sleeves and relishing a cool gentle breeze. The sky was an incredible cobalt blue, and I was at peace with the world. I snapped the following photo as I mellowed out in a sidewalk café in Buenos Aires. <\/p>\n

\"Image<\/p>\n

 <\/p>\n

I was in Buenos Aires teaching a VBScript class at the Microsoft offices down there, and as I sat sipping my espresso, I was the happiest guy in the world—awesome friends, excellent coffee, fantastic weather. What more could one want? <\/p>\n

KG, it is amazing how powerful certain memories can be, and how quickly they can be triggered. Maybe because I seldom drink coffee<\/font><\/a>, I can remember nearly every cup I ever drank and the occasion for it. The cup of espresso in Buenos Aires is high on my top 10 list of favorite cups of coffee.<\/p>\n

Enough daydreaming. Let’s get back to work. The path that will be used to store the module is stored in the $modulepath<\/b> variable. This path includes the path to the users’ modules folder plus a child folder that is the same name as the module itself. To create the new path, it is a best practice to use the Join-Path<\/b> cmdlet instead of doing string concatenation and attempting to manually build the path to the new folder. The Join-Path<\/b> cmdlet will put together a parent path and a child path to create a new path. This is seen here: <\/p>\n

$ModulePath = Join-Path -path $userPath `
               <\/span>-childpath (Get-Item -path $name).basename<\/p>\n

<\/font><\/font><\/p>\n

To Windows PowerShell 2.0, the Windows PowerShell team added a script property called basename<\/b> to the System.Io.FileInfo<\/b> class. This makes it easy to retrieve the name of a file without the file extension. Before Windows PowerShell 2.0, it was common to use the split<\/b> <\/i>method or some other string manipulation technique to remote the extension from the file name. Use of the basename<\/b> property is shown here:<\/p>\n

PS C:> (Get-Item -Path C:fsoHelloWorld.psm1).basename
HelloWorld<\/p>\n

<\/font><\/font><\/p>\n

The last step that needs to be accomplished is to create the subdirectory that will hold the module and to copy the module files into the directory. To avoid cluttering the display with the returned information from the New-Item<\/b> and Copy-Item<\/b> cmdlets, the results are pipelined to the Out-Null<\/b> cmdlet:<\/p>\n

New-Item -path $modulePath -itemtype directory | Out-Null
Copy-item -path $name -destination $ModulePath | Out-Null<\/p>\n

<\/font><\/font><\/p>\n

The entry point to the Copy-Modules.ps1 script calls the Test-ModulePath<\/b> function to determine if the users’ modules folder exists. It then uses the Get-ChildItem<\/b> cmdlet to retrieve a listing of all the module files in a particular folder. The –Recurse<\/b> parameter is used retrieve all the module files in the path. The resulting FileInfo<\/b> objects are pipelined to the ForEach-Object<\/b> cmdlet. The fullname<\/b> property of each FileInfo<\/b> object is passed to the Copy-Module<\/b> function. This is shown here:<\/p>\n

Test-ModulePath
Get-ChildItem -Path C:fso -Include *.psm1,*.psd1 -Recurse |
Foreach-Object { Copy-Module -name $_.fullName }<\/p>\n

<\/font><\/font><\/p>\n

The complete Copy-Modules.ps1 script is seen here. <\/p>\n

Copy-Modules.ps1<\/p>\n

<\/b><\/p>\n

\nFunction Get-OperatingSystemVersion
{
 <\/span>(Get-WmiObject -Class Win32_OperatingSystem).Version
} #end Get-OperatingSystemVersion<\/p>\n

Function Test-ModulePath
{
 <\/span>$VistaPath = “$env:userProfiledocumentsWindowsPowerShellModules”
 <\/span>$XPPath =  <\/span>“$env:Userprofilemy documentsWindowsPowerShellModules”
 <\/span>if ([int](Get-OperatingSystemVersion).substring(0,1) -ge 6)
   <\/span>{
     <\/span>if(-not(Test-Path -path $VistaPath))
       <\/span>{
         <\/span>New-Item -Path $VistaPath -itemtype directory | Out-Null
       <\/span>} #end if
   <\/span>} #end if
 <\/span>Else
   <\/span>{  <\/span>
  <\/span>   <\/span>if(-not(Test-Path -path $XPPath))
       <\/span>{
         <\/span>New-Item -path $XPPath -itemtype directory | Out-Null
       <\/span>} #end if
   <\/span>} #end else
} #end Test-ModulePath<\/p>\n

Function Copy-Module([string]$name)
{
 <\/span>$UserPath = $env:PSModulePath.split(“;”)[0]
 <\/span>$ModulePath = Join-Path -path $userPath `
               <\/span>-childpath (Get-Item -path $name).basename
 <\/span>New-Item -path $modulePath -itemtype directory | Out-Null
 <\/span>Copy-item -path $name -destination $ModulePath | Out-Null
}<\/p>\n

# *** Entry Point to Script ***
Test-ModulePath
Get-ChildItem -Path C:fso -Include *.psm1,*.psd1 -Recurse |
Foreach-Object { Copy-Module -name $_.fullName }<\/p>\n

<\/font><\/font><\/p>\n

Note: Scripting support does not need to be enabled in Windows PowerShell to use modules. However, to run the Copy-Modules.ps1 to install modules to the users profile, you will need script support. To enable scripting support in Windows PowerShell, use the Set-ExecutionPolicy<\/b> cmdlet. You could also use Xcopy to copy modules to the user’ modules folder. <\/p>\n

An easy way to work with modules is to create a couple of Windows PowerShell drives using the filesystem<\/b> provider. Because the modules live in a location that is not easily navigated to from the command line, and because the $PSModulePath<\/b> returns a string that contains the path to both the users’ and the system modules folders, it makes sense to provide an easier way to work with the modules location. To create a Windows PowerShell drive for the user module location, you use New-PSDrive<\/b> cmdlet, specify a name such as mymods<\/b>, use the filesystem<\/b> provider, and obtain the root location from the $PSModulePath<\/b> environmental variable by using the split<\/b> method from the .NET Framework string class. For the users’ modules folder, you use the first element from the returned array. This is shown here:<\/p>\n

PS C:> New-PSDrive -Name mymods -PSProvider filesystem -Root `
(($env:PSModulePath).Split(“;”)[0])<\/p>\n

WARNING: column “CurrentLocation” does not fit into the display and was removed
.<\/p>\n

Name           <\/span>Used (GB)     <\/span>Free (GB) Provider      <\/span>Root
—-           <\/span>———     <\/span>——— ——–      <\/span>—-
mymods                           <\/span>47.62 FileSystem    <\/span>C:Usersadministrator….<\/p>\n

<\/font><\/font><\/p>\n

The command to create a Windows PowerShell drive for the system module location is exactly the same as the one used to create a Windows PowerShell drive for the user module location, with the exception of specifying a different name such as sysmods<\/b> and choosing the second element from the array you obtain by using the split<\/b> method from on the $PSModulePath<\/b> variable. This command is seen here:<\/p>\n

PS C:> New-PSDrive -Name sysmods -PSProvider filesystem -Root `
(($env:PSModulePath).Split(“;”)[1])<\/p>\n

WARNING: column “CurrentLocation” does not fit into the display and was removed
.<\/p>\n

Name           <\/span>Used (GB)     <\/span>Free (GB) Provider      <\/span>Root
—-      <\/span>     <\/span>———     <\/span>——— ——–      <\/span>—-
sysmods                          <\/span>47.62 FileSystem    <\/span>C:WindowsSystem32Win…<\/p>\n

<\/font><\/font><\/p>\n

Note: I like to create my Windows PowerShell drives for the two module locations in my personal profile. In this way, the drives are always available when I need to utilize them.<\/p>\n

You can also write a script that creates Windows PowerShell drives for each of the two module locations. To do this, you first create an array of names for the Windows PowerShell drives. You then use a for<\/b> statement to walk through the array of Windows PowerShell drive names, and call the New-PSDrive<\/b> cmdlet. Because you are running the commands inside a script, it means the new Windows PowerShell drives by default would live wit\nhin the script scope. After the script ends, the script scope goes away. This means the Windows PowerShell drives would not be available after the script ended, which would defeat our purposes in creating them in the first place. To combat this scoping issue, you need to create the Windows PowerShell drives within the Global<\/b> scope, which means they will be available in the Windows PowerShell console after the script has completed running. To avoid displaying confirmation messages when creating the Windows PowerShell drives, you pipe the results to the Out-Null<\/b> cmdlet. <\/p>\n

In the New-ModulesDrive.ps1 script, another function is created. This function displays global filesystem<\/b> Windows PowerShell drives. When the script is run, the New-ModuleDrives<\/b> function is called. It is followed by calling the Get-FileSystemDrives<\/b> function. The complete New-ModulesDrive.ps1 script is shown here. <\/p>\n

New-ModulesDrive.ps1<\/p>\n

<\/b><\/p>\n

Function New-ModuleDrives
{
<#
    <\/span>.SYNOPSIS
    <\/span>Creates two PSDrives: myMods and sysMods
    <\/span>.EXAMPLE
    <\/span>New-ModuleDrives
    <\/span>Creates two PSDrives: myMods and sysMods. These correspond
    <\/span>to the users’ modules folder and the system modules folder respectively.
#>
 <\/span>$driveNames = “myMods”,”sysMods”<\/p>\n

 <\/span>For($i = 0 ; $i -le 1 ; $i++)
 <\/span>{
  <\/span>New-PsDrive -name $driveNames[$i] -PSProvider filesystem `
  <\/span>-Root ($env:PSModulePath.split(“;”)[$i]) -scope Global |
  <\/span>Out-Null
 <\/span>} #end For
} #end New-ModuleDrives<\/p>\n

Function Get-FileSystemDrives
{
<#
    <\/span>.SYNOPSIS
    <\/span>Displays global PS Drives that use the Filesystem provider
    <\/span>.EXAMPLE
    <\/span>Get-FileSystemDrives
    <\/span>Displays global PS Drives that use the Filesystem provider
#>
 <\/span>Get-PSDrive -PSProvider FileSystem -scope Global
} #end Get-FileSystemDrives<\/p>\n

# *** EntryPoint to Script ***
New-ModuleDrives
Get-FileSystemDrives<\/p>\n

<\/font><\/font><\/p>\n

\n

 <\/p>\n<\/p>\n

KG, that is all there is to using Windows PowerShell modules. Windows PowerShell Module Week will continue tomorrow. <\/p>\n

If you want to know exactly what we will be looking at tomorrow, follow us on Twitter<\/a> or Facebook<\/font><\/a>. If you have any questions, send e-mail to us at scripter@microsoft.com<\/font><\/a> or post them on the Official Scripting Guys Forum<\/font><\/a>. See you tomorrow. Until then, peace.<\/p>\n

\n

 <\/p>\n<\/p>\n

Ed Wilson and Craig Liebendorfer, Scripting Guys<\/p>\n

<\/span><\/b><\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

  Hey, Scripting Guy! I have been reading your articles about Windows PowerShell modules this week, but I am still a bit confused about where they go, how to get them there, and the best practice for dealing with them. Do you have any insight about how to actually work with Windows PowerShell module paths? […]<\/p>\n","protected":false},"author":595,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[51,52,3,4,45],"class_list":["post-51523","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-getting-started","tag-modules","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":"

  Hey, Scripting Guy! I have been reading your articles about Windows PowerShell modules this week, but I am still a bit confused about where they go, how to get them there, and the best practice for dealing with them. Do you have any insight about how to actually work with Windows PowerShell module paths? […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/51523","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/595"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=51523"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/51523\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=51523"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=51523"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=51523"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}